本文共 855 字，大约阅读时间需要 2 分钟。

1.为什么要分库分表

超大容量问题

性能问题

2.如何去做到

1）垂直切分

垂直分库：解决的是表过多的问题（用户库、订单库） 垂直分表：解决单表列过多的问题（100列是一个瓶颈）

2）水平切分

大数据表拆成小表（mysql一张表1000w是一个瓶颈，少于1000w出现问题那么就是应用层的问题）

3.常见的拆分策略

1）垂直拆分（er分片）

相关联的表划分在一个库，避免关联查询问题

2）水平拆分

一致性hash：根据id取模存储 范围切分：可以按照ID在某区间范围落在某个表 日期拆分：经常不访问的历史数据可以按日期拆分备份

4.拆分以后带来的问题

4.1 跨库join的问题

1）设计的时候考虑到应用层的join问题，尽量避免join问题

2）在服务层去做调用

//A服务里查询到一个listfor(list){//B服务通过该list去查询数据，来实现双库双表关联   bservice.select(list);}

3）全局表

数据变更比较少基于全局应用的表，如数据字典，在每个独立的子库里面都有。

4）做字段冗余（空间换时间的做法）

* 订单表。 商家id 商家名称 * 商家名称变更- 定时任务、任务通知

4.2 跨分片数据排序分页

每个表查询出来，在应用层组装起来拼接

4.3 唯一主键问题

• 用自增id做主键（分库的话有重复问题）
• UUID 性能比较低（太长，主键索引效率低）
• snowflake ：雪花算法
• mongoDB ：objectid
• zookeeper ：自动生成的递增id
• 数据库表：一张全局的自增主键表

4.4 分布式事务问题

多个数据库表之间保证原子性 ；保证原子性会出现性能问题，所以互联网公司用强一致性分布式事务比较少

分库分表最难的在于业务的复杂度，即水平分表的前提是已经存在大量的业务数据。而这个业务数据已经渗透到了各个应用节点

5.如何权衡当前公司的存储需要优化

1. 提前规划（主键问题解决、 join问题解决）
2. 当前数据单表超过1000W、每天的增长量持续上升

6.参考

转载地址：http://ppmxb.baihongyu.com/