在 MySQL 复制架构中，主从延迟是常见问题。请阐述在主从同步出现延迟时，你会采取哪些措施来应对和优化？
考察说明
考查对 MySQL 主从复制原理的理解以及面对延迟时的排查与优化能力。
回答思路
- 【回答框架 1】主从延迟指从库重放中继日志事件慢于主库写入，常见原因包括从库单线程回放、大事务、慢查询及硬件差异。优化思路围绕降低主库负载、控制复制延迟和分流读请求。
- 【回答框架 2】应对策略包括：并行复制，即开启多线程从库复制，例如 MySQL 5.6 后支持 schema 级并行，5.7 支持基于事务的并行回放；对大事务拆分为小事务；优化慢查询并确保从库索引与主库一致。
- 【回答框架 3】若延迟无法避免，可通过读写分离架构将实时性要求高的请求路由到主库，从库承担可容忍延迟的查询；也可使用半同步复制减少数据丢失风险，但注意其可能增加主库写入延迟。
- 【回答框架 4】监控方面，通过 SHOW SLAVE STATUS 中的 Seconds_Behind_Master 观察延迟值，结合从库的 IO 和 SQL 线程状态、主库 binlog 位置，定位瓶颈在 IO 还是在 SQL 回放。
- 【关键点 1】主从延迟的根本原因是从库回放速度跟不上主库写入，常用指标为 Seconds_Behind_Master。
- 【关键点 2】并行复制是解决延迟的主要手段，需根据版本和事务特征开启。
- 【关键点 3】大事务和慢查询会放大延迟，应拆分事务并优化查询。
- 【关键点 4】读写分离是应对延迟的应用层方案，需保证一致性需求。
- 【关键点 5】监控主从状态和延迟趋势，及时调整复制策略。
- 【易错点 1】不要误以为 Seconds_Behind_Master 为 0 就代表数据完全一致，它还受刷盘和网络影响。
- 【易错点 2】并行复制不能解决所有延迟，若存在单表频繁更新，仍可能串行。
- 【易错点 3】半同步复制可能增加写入时延，需权衡可用性和一致性。