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

[LoremIpSum]

不少技术文章都直接引用了这个观点，但没说为什么？有大佬解释下这个理论依据吗？

[zhilincom]

听说 MySQL 单表超过 1000 万行性能会急剧下降。

[akira]

这应该是个经验数字，不一定绝对对。 但是如果你只有几十 几百万的数据，就大概率是直接用就好，不需要考虑那么多事情

[dayeye2006199]

可能和 b 树的深度，和 Page 的大小有关

[wxf666]

反正 20 天前，在一个 [帖子]( https://www.v2ex.com/t/882773 ) 里，有很多人反映，MySQL 单表存 1~2 亿（#11 楼 #16 #18 #19 #21 #35 ）、4 亿（#27 ）、10 亿（#36 ）、20 亿（#28 ）都没问题，查询也很快（< 10 ms ，#27 #28 ）

[wxf666]

我在那个帖子里的 3 楼，也问了个类似的问题，也给出一点猜测（但没人理我。。）

[chendy]

1. 经验数字
2. 阿里（也许）自己有足够完善的组建处理分库分表
3. 阿里（也许）可以通过传播这个数字，卖更多的数据库或者其他服务

[liuzhaowei55]

备份、恢复数据的难度，太大了也是灾难

[GTim]

很多业务，估计一个小时就要分一次表了

[makelove]

才 500 万，哪怕机械硬盘时代都毫无问题，更别提现在的高速 SSD

[jorneyr]

分库分表没那么好玩，应用端需要精心设计，不能像单库那样随心所欲的写 SQL 。

[Maboroshii]

之前有人说是 2000w 行，查了一下是索引数深度的效率相关

[sadfQED2]

@jorneyr 可以加一个 db proxy 层，这一层屏蔽分表分库细节，你代码里面依然可以当单表使用，随心所欲的写 sql 。

[bthulu]

那是说的机械硬盘经验值, 还是偏保守的那种.
现在的 M.2 SSD, 三星 980PRO, 随机 4k 读写速度是普通机械的 500 倍往上, 同样的, 500 万*500=25 亿, 也就是说, 保守点估计 25 亿行数据再考虑分库分表, 胆子大一点的, 100-1000 亿行数据以上再去考虑这个问题.

[jorneyr]

@sadfQED2 分布式数据库一般都有 DB Proxy 的，但是 SQL 落到多个库，数据量大的时候，Proxy 每个节点都取数据来处理的时候，一是慢，二是容易内存超量，例如有 1024 个节点，要查询 1000 行，不巧写的 SQL 没有分片键，那么就要去这 1024 个节点上各自都获取 1000 行数据，Proxy 得到 1024 * 1000 行数据进行 Merge Sort ，然后再判断一次取出合适的 1000 行。

最直观的是使用 Sharding Sphere ，或者看看 TDSql 等的设计文档，没那么自由。

[Biggoldfish]

一张 table 2GB 就性能下降到不可接受了，怕是在用十年前的 DB 吧

[cooper]

https://mp.weixin.qq.com/s/XX_NkIIf_PLyU4IE6lEEYQ

[lmshl]

老民科八股文了，遗毒万年
生产环境近两亿行的主表，0.2ms 查询时间，分库分表？分个 J2

[lmshl]

我怀疑写八股文和背八股文的人不懂什么是 O(log(n))，就硬背树深了一层

健康项目中：低效率查询，未命中索引的查询应该在 Code Review 阶段被驳回的。过早期的分库分表还会极大提高总持有成本，百害而无一利。因为只需要简单的主从读写分离架构就可以支撑到数万 TPS 了。

[dog82]

这应该是个经验之谈。主要是看表怎么用，如果仅仅是主键查询 10 亿都不要分表。

[ration]

什么数据库，什么版本，硬件性能咋样，如果是 mysql 用的是什么引擎，条件不充分都是空谈。我觉得测试之后才能有结果，真正实践的话也要对数据库进行测试。