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

今天，商量一个有味的话题：MySQL 单表数据到达多少时才需要思考分库分表？有人说 2000 万行，也有人说 500 万行。那么，你觉得这个数值多少才适宜呢？

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

再后来，alibaba《Java 开发手册》提出单表行数超越 500 万行或者单表容量超越 2GB，才引荐停止分库分表。对此，有阿里的黄金铁律支撑，所以，许多人设计大数据储备时，多会以此为标准，停止分表操纵。

那么，你觉得这个数值多少才适宜呢？为什么不是 300 万行，或者是 800 万行，而是 500 万行？或许你会说这个大概就是阿里的最好实战的数值吧？那么，问题又来了，这个数值是怎样评估出来的呢？稍等半晌，请你小小思索一会儿。

事实上，这个数值和实际记载的条数无关，而与 MySQL 的配置乃至机器的硬件有关。由于，MySQL 为了提高机能，会将表的索引装载到内存中。InnoDB buffer size 足够的状况下，其能完成全加载进内存，查询不会有问题。但是，当单表数据库抵达某个量级的上限时，致使内存没法储备其索引，使得之后的 SQL 查询会发生磁盘 IO，从而致使机能下落。当然，这个还有详细的表构造的设计有关，终究致使的问题都是内存限制。这里，增添硬件配置，大概会带来吹糠见米的机能晋升哈。

那么，我关于分库分表的观念是，需要结合实际需求，不宜过度设计，在项目一开端不采纳分库与分表设计，而是随着业务的增长，在没法连续优化的状况下，再思考分库与分表提高系统的机能。对此，alibaba《Java 开发手册》补充到：假如估计三年后的数据量基本达不到这个级别，请不要在创立表时就分库分表。那么，回到一开端的问题，你觉得这个数值多少才适宜呢？我的倡议是，按照本身的机器的状况综合评估，假如心里没有标准，那么临时以 500 万行作为一个统一的标准，相对而言算是一个比力折中的数值。

更多MySQL相关技术文章，请拜访MySQL教程栏目停止学习！

以上就是MySQL单表数据不要超越500万行：是经历数值，还是黄金铁律？的具体内容，更多请关注百分百源码网其它相关文章！