一、分库分表的原因
- MySQL单机能力有限
- 百万级表可以通过主从、读写分离、优化索引等方式解决性能问题
- 千万级表时，性能开始下降，成为系统瓶颈
- 需要做数据切分（Sharding），使用分布式的思路解决性能问题
二、切分方式
1、垂直切分
(1) 垂直分库
根据业务内容将不同的业务数据分库保存，彼此之间通过API接口获取数据。
(2) 垂直分表
即宽表拆分，减少每条数据的容量
优点
- 业务解耦
缺点
- 增加开发复杂度，必须使用接口聚合数据
- 要解决分布式事务问题
- 单表数据量大的问题仍未解决。必须结合水平拆分
2、水平切分
(1) 单库分表
将一张大表，切分成多张表结构相同、只保存一部分数据的子表，所有子表存于同一个库内。
问题点在于所有的子表仍然会竞争同一台服务器的资源（CPU、内存、IO）
(2) 分库分表
拆分出的子表散列到不同的数据库中
优点
- 业务系统改造工作量不大
缺点
- 要解决跨分片的事务一致性
- 跨库做关联查询（join）时性能差
- 维护工作量大
三、主要技术点
1、挑选适合的主流分库分表中间件
- MyCAT
- atlas
- sharding-jdbc
……
2、水平拆分时数据如何散列
(1)根据主键（比如ID）或者增改时间的区间散列到相应的表
优点：
- 扩容方便，不用做数据迁移
- 数据定位速度快
- 单表数据量可控
缺点：
- 由于冷热数据的问题，造成负载不均衡
(2)hash函数散列。比如hash值取模
优点：
- 数据分布均衡，系统负载均衡
缺点：
- 系统扩容时需要大量数据迁移，维护工作量大
3、解决事务一致性问题
- 有强一致需求时：两段提交（XA协议）等。开发难度大，系统性能差。
- 尽可能争取只需要保证最终一致性：做事务补偿即可
4、全局唯一主键问题
twitter的snowflake算法（雪花算法）及其各种衍生算法
5、分页、排序
需要先做各个分片数据的聚合，然后再做分页、排序，开发工作量大
