# 主从同步

1. 主库的修改操作记录到binlog
2. 从库启动io线程，同步主库的binlog到自己的delay log
3. 从库的循环thread定时扫描delay log的数据刷到磁盘中

在步骤二中 根据同步的情况不同，从库具有不同的可靠性

1. 全提交策略：事务需要等到从库全部同步delay log完毕才提交
2. 半提交策略：事务只需要等待任一个从库同步完delay log完毕后提交
3. 事务不关心从库delay log的同步情况

根据binlog记录形式的不同，有以下三种分类

1. row，基于行的修改
2. 修改记录，基于语句的修改
3. mix，先基于语句的修改，如果不行，再基于行

# 读写分离

情况：请求过多，单个库处理吃力时 采用主从同步的方案，将db分成主库和从库，主库只接收写请求，从库接收读请求 如何处理事务？ 对于事务的情况，统一走主库

# 分库分表

当数据量过大，读写分离方案已经hold不住的时候，这时我们就需要进行分库分表 方案分为垂直分表和水平分表

# 垂直分表

将一个字段很多的表，拆分成两个表

# 水平分表

当表中的数据过多，一般而言，当一次io需要4次（大概在一千万左右），就可以开始考虑采取分表策略。将一个表中的数据，根据一定的规则，拆分成n个表，将这n个表，存放在m个库中 数据拆分规则：

1. 根据数据量拆分，1~1000W放在表1，1000W~2000W放在表2
2. 根据主键进行hash取模
3. 根据时间拆分，每个月份的数据落一张表

路由架构

1. 客户端路由，使用sdk的形式，代理数据源（druid、c3p0等），在sdk中，完成hash路由以及数据聚合的功能

优点： 缺点：

2. 服务端路由，在业务与db之间再加一层路由服务，业务直接访问路由层，有路由层与db交互

优点： 业务无感 缺点：

1. 路由需要解决自己的单点问题
2. 多一次io

拆分后的问题

1. 连表查询
2. 分页查询

总之，查询不再友好 替代方案：使用tiDB来代替水平分表