苹果华为强势，手机市场又洗牌了

分库分表

分库分表则是将切分出来的子表，分散到不同的数据库中，从而使得单个表的数据量变小，达到分布式的效果。

优点：

•  解决高并发时单库数据量过大的问题，提升系统稳定性和负载能力
•  业务系统改造的工作量不是很大

缺点：

•  跨分片的事务一致性难以保证
•  跨库的join关联查询性能较差
•  扩容的难度和维护量较大，（拆分成几千张子表想想都恐怖）

三、数据该往哪个库的表存？

分库分表以后会出现一个问题，一张表会出现在多个数据库里，到底该往哪个库的表里存呢？

1、根据取值范围

按照时间区间或ID区间来切分，举个栗子：假如我们切分的是用户表，可以定义每个库的User表里只存10000条数据，第一个库userId从1 ~ 9999，第二个库10000 ~ 20000，第三个库20001~ 30000……以此类推。

优点：

•  单表数据量是可控的
•  水平扩展简单只需增加节点即可，无需对其他分片的数据进行迁移
•   能快速定位要查询的数据在哪个库

缺点：

•  由于连续分片可能存在数据热点，如果按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询

2、hash取模

hash取模mod（对hash结果取余数 (hash() mod N)）的切分方式比较常见，还拿User表举例，对数据库从0到N-1进行编号，对User表中userId字段进行取模，得到余数i，i=0存第一个库，i=1存第二个库，i=2存第三个库….以此类推。

这样同一个用户的数据都会存在同一个库里，用userId作为条件查询就很好定位了

优点：

•  数据分片相对比较均匀，不易出现某个库并发访问的问题

缺点：

• 但这种算法存在一些问题，当某一台机器宕机，本应该落在该数据库的请求就无法得到正确的处理，这时宕掉的实例会被踢出集群，此时算法变成hash(userId) mod N-1，用户信息可能就不再在同一个库中。

四、分库分表后会有哪些坑？

1、事务一致性问题

由于表分布在不同库中，不可避免会带来跨库事务问题。一般可使用"XA协议"和"两阶段提交"处理，但是这种方式性能较差，代码开发量也比较大。

通常做法是做到最终一致性的方案，往往不苛求系统的实时一致性，只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。

2、分页、排序的坑

日常开发中分页、排序是必备功能，而多库进行查询时limit分页、order by排序，着实让人比较头疼。

分页需按照指定字段进行排序，如果排序字段恰好是分片字段时，通过分片规则就很容易定位到分片的位置；一旦排序字段非分片字段时，就需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户，过程比较复杂。

3、全局唯一主键问题

由于分库分表后，表中的数据同时存在于多个数据库，而某个分区数据库的自增主键已经无法满足全局

唯一，所以此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。

可以参考我之前写的这篇文章《一口气说出 9种 分布式ID生成方式，面试官有点懵了》

五、分库分表工具？

自己开发分库分表工具的工作量是巨大的，好在业界已经有了很多比较成熟的分库分表中间件，我们可

以将更多的时间放在业务实现上

（编辑：南通站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!