分库分表

Sharding-jdbc：SQL语法支持比较多，支持分库分表，读写分离，分布式id，柔性事务（最大努力送达型事务、TCC事务）。不用部署，运维成本低，不需要代理层的二次转发请求，性能很高。升级则需要各个系统都升级。

Mycat：缺点在于需要部署，运维成本高，对各个项目是透明的，升级只需要升级中间件。

rang：按时间分，例如一个月一个库，但是一般都访问最新数据的，会有大量请求到新的库去。

hash：平均每个库的数据量和请求压力。扩容比较麻烦，会有数据迁移过程，重新计算hash。

怎么迁移：停机迁移方案（把旧库数据导到新库）；双写迁移方案（新数据进入新旧库，后台数据迁移临时从旧到新，根据gmt_modify最新保留新旧库重复数据）。

MySQL主从复制原理：主库将变更写入binglog日志，然后从库链接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个relay中继日志中，接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在本地再执行一遍SQL，这样就可以保证自己跟主库数据一样。会存在延迟，所以mysql有两个机制，半同步复制（要求主库接到从库写入本地relaylog返回ack才算成功，解决主库数据丢失），并行复制：从库开启多个线程，并行读取relaylog中不同库的日志，然后并行重放不同库的日志。

延时较严重解决办法：

• 分库，单个主库承受的写减少，主从延迟降低。
• 打开mysql支持的并行复制，但是单库写并发达到2000/s，没有意义。
• 代码避免改完再查，再做逻辑查处理。
• 代码上是改完要再查出来执行，这个查询改直连主库，不太推荐。