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万行：是经验数值，还是黄金铁律？的细致内容，更多请关注 百分百源码网 其它相干文章！
