今天讨论一个有趣的话题：MySQL单表有多少数据需要考虑分库分表？有人说2000万行，也有人说500万行。那么，你觉得这个值多少合适呢？曾经在中国互联网技术圈流传着这样一句话：如果MySQL单表数据量大于2000万行，性能会大幅下降。其实这个传言据说最早起源于百度。具体情况大概是这样的。DBA在测试MySQL性能时发现，当单表量在2000万行量级时，SQL操作性能急剧下降。因此，结论由此而来。然后据说百度的工程师跳槽到业内其他公司，也把这个信息带走了。因此，业内流传着这样的说法。后来阿里巴巴《Java 开发手册》提出单表行数超过500万行或者单表容量超过2GB才推荐分库分表。这是阿里的金铁律支撑的。因此，在设计大数据存储时，很多人以此为标准进行分表操作。那么，你觉得这个值多少合适呢？为什么不是300万行，或者800万行，而是500万行？或许你会说，这可能是阿里最好的实战价值？那么，问题又来了，这个值是怎么评估的呢？稍等一下，请想一想。其实这个值与实际记录数无关，与MySQL的配置和机器的硬件有关。因为，为了提高性能，MySQL会将表的索引加载到内存中。当InnoDBbuffersize足够大的时候，可以完全加载到内存中，查询不会有问题。但是，当单表数据库达到一定量级的上限时，内存无法存储其索引，以至于后续的SQL查询会产生磁盘IO，导致性能下降。当然这也和具体表结构的设计有关，最后就是内存限制问题。在这里，增加硬件配置可能会带来立竿见影的性能提升。那么，分库分表我的观点是需要结合实际需求，不宜过度设计。项目初期不应该采用分库分表的设计，但是随着业务的增长，无法进一步优化时，再考虑分库分表来提高系统的性能.对此，阿里巴巴《Java 开发手册》补充道：如果三年后的数据量预计根本达不到这个水平，请不要在建表时分库分表。那么，回到一开始的问题，你觉得这个值适合做什么用？我的建议是根据自己机器的情况综合评估。如果心中没有标准，那就暂时以500万行作为统一标准。可以看作是一个比较折衷的值。
