阿里巴巴技术手册:单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表的理论依据？

物理定律还有适用条件呢，更何况数据库的访问模式不同，硬件、软件也会不断地迭代和优化

分表并不会让事情变得更简单，仅仅是用逻辑复杂度代替空间复杂度而已

@lmshl 是不是民科不重要,重要的在于程序员的素养,如果考虑到外包团队普遍拉垮的质量,以及 java mysql 这些在企业应用中的高占比,我赞同 500w 分表

应该没这么夸张。
自建的文件元数据索引表没能正确处理符号链接 loop ，结果整出来几百 G 的表，直到手工执行 count(*)的时候才发现不对劲，其它操作基本无感

应该是性能目标不一致造成的错觉

[查询没有问题] 这个本身就很主观的东西，不同企业不同场景对 [查询没问题] 的定义可以差很大的啊

其他企业敢说自己的查询目标要求与阿里场景和要求一致吗？

阿里的技术手册，其他实体应当仅供参考。

之前生产环境有张过亿的表，其实表大了 查询还好，插入更新的时候，cpu 磁盘都会飙升，而且索引建的不科学的话，大表真的是噩梦，大表再数据插入的时候，还不稳定，时间慢，所以我感觉查询并不是分库分表的原因
这种情况在数据千万级别的时候就慢慢开始显现，但是这个 500W 的数字我也不知道怎么得出的

过亿有索引的查询肯定没问题。

有没有人试过修改、更新、和连表的性能？

@mmdsun insert 跟 update 的时候会有问题 如果 update 的范围过大 可能该表就卡住了一样 而且时间还不稳定 尤其是索引多一点的时候 简直是噩梦

查单条肯定随便过亿，其他操作我擦我不好说

实际工作中遇到过表数据超过两千万的情况，没有分表，是公司内 IM 的聊天记录。
结论是：查询、插入，以及主键更新，甚至索引做的不错，条件查询、翻页也还可以。
但是：开发新功能时，表结构变更，一个不注意，就是灾难。变更一次锁表 20 分钟。

表设计的垃圾才需要

这当然是经验只谈.

几百万的表, 单表查基本没事.

越大单表风险越大, 还是趁早拆.

它就是随便一说，不要这样机械，一旦启用分表，你的程序也要对应的修改，分表的好处是：系统具备横向扩容的能力. 流量大幅度上涨之后，加点机器就能抗住，如果没有这个需求就不需要扩

只要硬盘够大，单表存放数量随便

小马过河，自己趟一趟才知道深浅。索引做得如何、SQL 复杂度、硬件配置、每行数据的数据量都会对结果有影响。有十几亿记录数的表也跑得欢，也遇到过百万的表就已经很慢。

分表分库这些都是有代价的，分了以后业务开发难度会明显增大，越复杂的业务越是如此。
很多公司负责技术架构的人并不参与业务开发，说得不好听，为了自己的 KPI ，纸上谈兵拍脑袋定方案，害人不浅。

分不分表，怎么分，都要看具体业务和原有设计。

超过 500 万行或 2GB 才推荐，也就是说不超过 500 万行或 2GB ，不推荐分表，因为完全没有这个必要。

我们公司以前是 800w 行，但实际生产上也有超过 4000w 行的表跑着

甚至没提硬件。。就嗯背八股

我记得 oracle 是 1 亿，mysql 不至于这么拉胯吧？