分库分表的起源

1.为什么要分库分表

超大容量问题
性能问题

2.如何去做到

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

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

3.常见的拆分策略

1）垂直拆分（er分片）
相关联的表划分在一个库，避免关联查询问题

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

4.拆分以后带来的问题

4.1 跨库join的问题

1）设计的时候考虑到应用层的join问题，尽量避免join问题
2）在服务层去做调用

//A服务里查询到一个list
for(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.参考

大众点评订单系统分库分表实践
mysql分表+查询