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

12 年的时候，mysql 免费版 大概 600 多万 数据是个分界线

InnoDB 的一页默认是 16KB ，其中有 100 多字节是头部等不用于存储数据的，这里先忽略。
索引页的每行要存储一个主键（假设是 int ，4 字节）和一个页号（ 4 字节），共计 8 字节。即一页最多存储 2K 条。
以一个 3 层的 B+ 树来计算，前两层是索引页，最多索引 2K * 2K = 4M 个节点。
假设表的每行占用的空间是 1KB ，那么一个数据页（叶子节点）最多存储 16 条数据，所有节点共可以存储 64M 条数据（ 64GB 大小）。
超过这个量时，要用 4 层的 B+ 树，那么 IO 次数就至少多出 1/3 ，索引也很难全放在内存中，肯定会大幅影响性能。

但是题目中提到的 500M 行和 2GB 并不是一个固定值，如果主键和每行占用的空间较小，就能存放更多的页。甚至你还能修改 innodb_page_size ，配置成更大的页，以在一页中存储更多行（但是可能造成 IO 的浪费，因为每次至少读一页）。

@keakon 非常赞

之前一个人能搞定, 分表后需要一个团队维护. 对部门有利.

我们存了十几亿数据，看你怎么查，不是所有查询都会很慢

阿里人家数据库实例是什么规格都没给你说, 你怎么确定自己的实例规格要按照 500w 或 2GB 来呢, 阿里的技术手册, 就看看就行吧. 经验值始终要去躺一次才知道什么效果, 没必要强硬生套.

@wxf666
1. 十年前的 mysql 的确不太行（ 5.7 之前）
2. 十年前的 CPU 性能瓶颈也很大，不分库存在 CPU 瓶颈
3. 之前的 Disk 是 HDD ，现在大部分是 ssd ，导致数据库性能有急剧提升。
综上，以前的观点和现在大家的体感不一致很正常。

我们单表 670GB 数据 OLTP 查询 基本在 20-30ms