读写分离需要注意
什么情况下会出现主从延迟
对于读写分离场景，最大的问题就是：主从延迟
可能导致主从延迟的场景：
- 大表 DDL
- 大事务
- 主库 DML 并发大
- 从库配置差
- 表上无主键
- 等等
读写分离怎样应对主从延迟
判断主从是否延迟
- 判断 Seconds_Behind_Master 是否等于 0
Seconds_Behind_Master 是在从库上执行 show slave status 时返回的其中一项，表示从库延迟的秒数。 其计算方法是：从库服务器当前的时间戳与二进制日志中的事件的时间戳（在主库上的写入时间）相对比得到的。
某些情况下，Seconds_Behind_Master 并不一定准确。比如网络中断时，Seconds_Behind_Master = 0 ，并不能代表主从无延迟。
- 对比位点
如果 Master_Log_File 跟 Relay_Master_Log_File 相等，并且 Read_Master_Log_Pos 跟 Exec_Master_Log_Pos 相等，则主从无延迟。
通过show slave status 返回的参数，用来查询主从复制的状态：
- Master_Log_File：IO 线程正在读取的主库 binlog 文件名
- Relay_Master_Log_File：SQL 线程最近执行的事务对应的主库 binlog 文件名
- Read_Master_Log_Pos ：IO 线程正在读取的主库 binlog 文件中的位点
- Exec_Master_Log_Pos ：SQL 线程最近读取和执行的事务对应的主库 binlog 文件中的位点
- GTID
如果开启了 GTID 复制，则可以对比 Retrieved_Gtid_Set 和 Executed_Gtid_Set 是否相等，相等则把读请求放到从库，有差异则读请求放到主库。
开启 GTID 两个参数才会有值，解释如下：
- Retrieved_Gtid_Set：从库收到的所有日志的 GTID 集合
- Executed_Gtid_Set：从库已经执行完的 GTID 集合
采用半同步复制
跟传统的异步复制相比，半同步复制保证了所有给客户端发送过确认提交的事务，从库都已经收到这个日志了。因此出现延迟的概率会小很多.
等待同步完成
报表类业务
