MySQL分库分表无线扩容后的瓶颈及解决方案

我们知道大多数公司都是从单体应用开始的，即便现在抗住双十一流量洪峰的淘宝，它最早用的也是：

LAMP（Linux+Apache+MySQL+PHP）。

对于任何一个刚起步的项目来说，选择简单快速的方式来实现无可厚非。

一旦架构开始变得复杂往往是因为业务的体量越来越大，用户量以及流量开始增加，服务器的性能就会受到挑战，架构演进就成为了我们不得不的选择。

随着我们手里的数据越来越多，SQL 操作越来越慢，数据库就会成为瓶颈。这个时候我想你一定会想到分库分表，从而突破网络IO、硬件资源、连接数的限制，然后胸有成竹地拍拍胸脯说：“只要我数据库能无限扩容不就万事大吉了！”

先别太兴奋，你需要想一想，分库分表可能带来的棘手问题，比如：

• 数据库连接过多，如果每个RPC都要连接所有的库，扩容则会导致连接数增加，需要考虑单元化；

• 事务一致性问题，解决方案包括2PC、3PC、TCC、消息事务、最大努力通知等；

• 跨库关联查询问题，我们可以考虑的方案包括全局表、字段冗余、系统层组装、ER表；

• 翻页、排序、函数计算问题，需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户；

• 全局主键避