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

Posted 2021-04-01 秃头程序员

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

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

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

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

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

客户端链接 Mysql 的 Server 层，Server 层会对 sql 进行语法解析和优化并生成执行计划，然后调用存储引擎提供的接口获取要查询的数据。

存储引擎层从计算机文件系统上读取对应的文件中的数据返回给 Server 层，Server 层再将数据返回给客户端。

存储引擎不了解的话，使用 InnoDB 就行，这也是比较常用的。

Redis 为什么会比 Mysql 快，很大的原因是 Redis 的数据都在内存中，再加上比较好的数据结构，查询的速度当然不是一个量级的。但同时 Redis 不会存储那么多的数据量，几个 T 的内存还是挺贵的。

Mysql 将数据储存在硬盘上，为了提高查询速度，比较好的做法是将索引数据和一部分热数据（经常访问的数据）放到内存中（Mysql 的 Buffer Poll）。

当检索数据的时候，Mysql 通过索引查找，就可以知道数据在磁盘哪块了，从硬盘对应位置读取对应的数据到内存中返回给客户端。

如果查询的时候没有走索引就需要扫描整个表数据文件，因为内存比硬盘小，会不停的从硬盘读取表中的一部分数据到内存，然后在内存中筛选出符合要求的数据，再去硬盘读取一部分数据做筛选直到整个表数据读取一遍。如果你有 20 g 数据，你想一下需要读取多长时间。

Mysql 8.0 相对 Mysql 7.0 性能上有很大提升，条件允许建议使用 Mysql 8.0。

（免责声明：图文来自网络，若有侵权，请联系秃头程序员后台删除）

推荐阅读

秃头程序员

秃头程序员

我知道你在看哟