决定分库分表的原因有哪些？

写在前面

前几天梁大发表了mysql单表500w数据分表的铁律，也参与了回复，结果同一天隔壁组面试，正好问了下面试者这个问题，面试官想在多方面考察面试者技术扎实程度，结果面试者回答的不好，所以整理一篇，决定分库分表的原因有哪些？

单表数据量角度

这是梁大文章中阐述的主要原因之一：

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

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

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

单行数据特点角度

这是飞哥的观点，分库分表原因和每行记录大小有关系，因为b+ tree索引叶子节点保存真实记录数据，每条记录大小决定了每个叶子节点能保存多少记录，影响了b+tree索引树的高度，从而影响了性能。

业务特点角度

春哥大魔王的角度是从业务角度切入，比如虚拟机mysql实例的写qps瓶颈大概在3k左右，物理机mysql实例的写qps瓶颈大概可以摸高到1w，但是随着业务场景发展，随便搞个大促，或者推广，整个系统的瓶颈就会暴露出来，所以需要提早做分库分表了。

连接数角度

另一个角度可以是连接数，因为随着单个mysql实例连接的下游服务越来越多，导致mysql和服务之间建立大量的长连接，连接数量是完全有上限的，可以通过读写分离，分库分表等多个角度降低连接数造成的性能问题。

最后

所以分库分表，数据量只是其中的因素之一，可以从机器配置，mysql原理，连接池，业务特点等多个角度考虑。

转载于:https://my.oschina.net/u/1000241/blog/3064238