MySQL单表数据不要超过500万行：是经验数值，仍是黄金铁律？

原文地址： 梁桂钊的博客

博客地址：http://blog.720ui.com

欢迎关注公众号：「服务端思惟」。一群同频者，一块儿成长，一块儿精进，打破认知的局限性。

今天，探讨一个有趣的话题：MySQL 单表数据达到多少时才须要考虑分库分表？有人说 2000 万行，也有人说 500 万行。那么，你以为这个数值多少才合适呢？

<img style="width:500px;" src="https://cdn.nlark.com/yuque/0...;display=inline&height=250&name=image.png&originHeight=500&originWidth=900&size=153164&status=done&width=450" alt="" align=center />

曾经在中国互联网技术圈广为流传着这么一个说法：MySQL 单表数据量大于 2000 万行，性能会明显降低。事实上，这个传闻听说最先起源于百度。具体状况大概是这样的，当年的 DBA 测试 MySQL性能时发现，当单表的量在 2000 万行量级的时候，SQL 操做的性能急剧降低，所以，结论由此而来。而后又听说百度的工程师流动到业界的其它公司，也带去了这个信息，因此，就在业界流传开这么一个说法。

再后来，阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。对此，有阿里的黄金铁律支撑，因此，不少人设计大数据存储时，多会以此为标准，进行分表操做。

那么，你以为这个数值多少才合适呢？为何不是 300 万行，或者是 800 万行，而是 500 万行？也许你会说这个可能就是阿里的最佳实战的数值吧？那么，问题又来了，这个数值是如何评估出来的呢？稍等片刻，请你小小思考一下子。

<img style="width:500px;" src="https://cdn.nlark.com/yuque/0...;display=inline&height=540&name=image.png&originHeight=1080&originWidth=1080&size=502988&status=done&width=540" alt="" align=center />

事实上，这个数值和实际记录的条数无关，而与 MySQL 的配置以及机器的硬件有关。由于，MySQL 为了提升性能，会将表的索引装载到内存中。InnoDB buffer size 足够的状况下，其能完成全加载进内存，查询不会有问题。可是，当单表数据库到达某个量级的上限时，致使内存没法存储其索引，使得以后的 SQL 查询会产生磁盘 IO，从而致使性能降低。固然，这个还有具体的表结构的设计有关，最终致使的问题都是内存限制。这里，增长硬件配置，可能会带来立竿见影的性能提高哈。

那么，我对于分库分表的观点是，须要结合实际需求，不宜过分设计，在项目一开始不采用分库与分表设计，而是随着业务的增加，在没法继续优化的状况下，再考虑分库与分表提升系统的性能。对此，阿里巴巴《Java 开发手册》补充到：若是预计三年后的数据量根本达不到这个级别，请不要在建立表时就分库分表。那么，回到一开始的问题，你以为这个数值多少才合适呢？个人建议是，根据自身的机器的状况综合评估，若是内心没有标准，那么暂时以 500 万行做为一个统一的标准，相对而言算是一个比较折中的数值。

写在末尾

【服务端思惟】：咱们一块儿聊聊服务端核心技术，探讨一线互联网的项目架构与实战经验。让全部孤军奋战的研发人员都找到属于本身的圈子，一块儿交流、探讨。在这里，咱们能够认知升级，链接顶级的技术大牛，链接优秀的思惟方式，链接解决问题的最短路径，链接一切优秀的方法，打破认知的局限。

更多精彩文章，尽在「服务端思惟」！