数据库读写分离后主从延迟该怎么解决

主从延迟不可能被彻底消灭，只能被"分级处理"：把真正怕延迟的读强制打到主库，其余的读用半同步复制 + 并行回放 + 延迟感知路由，把窗口压到毫秒级；任何宣称"调一个参数就能做到零延迟"的说法都不成立。下面按"根因 → 业务兜底 → 数据库参数 → 架构路由 → 监控"五步给出可落地的做法。

主从延迟为什么会发生？

结论：绝大多数主从延迟不是网络慢，而是从库的回放速度跟不上主库的写入速度。

一是并发度不对等：主库 32 个线程并发写，MySQL 5.6 之前从库只有一个 SQL 线程串行回放，写入量一大延迟就持续堆积。二是大事务：一个事务里塞 10 万行 UPDATE，从库必须整个事务回放完才对上层可见，期间延迟直接飙到几十秒。三是资源不对等：从库硬件比主库弱，或者从库上跑报表、备份、离线任务抢走了 IO。四是网络：同机房 RTT 通常 0.1-1ms，影响很小；跨机房或带宽打满时才会成为主因。

所以排查顺序应该是：先看有没有大事务和慢 SQL，再看从库 CPU/IO 是否被挤占，最后才怀疑网络。

读写分离后，哪些读必须强制走主库？

结论：所有"写完之后立刻要读到自己刚写的数据"的场景，必须强制路由到主库，这是最简单也最可靠的一招。

典型场景包括：下单成功后跳转订单详情、支付回调后查询支付状态、注册成功后立即登录、扣减库存后回显余量。这些请求对延迟的容忍度是 0。

实现方式有两种。第一种是逻辑标记：用 ShardingSphere 时调用 HintManager.getInstance().setWriteRouteOnly() 强制走主库；用 MyBatis 时可以自定义注解 + AOP 切换数据源。第二种是位点等待：写入后拿到 GTID，读取前执行 SELECT WAIT_FOR_EXECUTED_GTID_SET('gtid集合', 1)，最多等 1 秒，从库追上就正常读，超时就降级走主库。MySQL 8.0.26 及以上版本可以用 SOURCE_POS_WAIT() 替代 MASTER_POS_WAIT()。

MySQL 参数怎么调才能把延迟压下来？

结论：半同步复制（AFTER_SYNC）+ 并行复制（LOGICAL_CLOCK 或 WRITESET）+ 拆分大事务，是把延迟从秒级压到毫秒级的三件套。

半同步复制：主库设置 rpl_semi_sync_master_enabled=ON，rpl_semi_sync_master_wait_point=AFTER_SYNC（MySQL 5.7 起的默认值，比 5.6 的 AFTER_COMMIT 少一次提交等待），rpl_semi_sync_master_timeout=1000（毫秒，超时自动降级为异步，避免主库被从库拖死）。

并行复制：设置 slave_parallel_type=LOGICAL_CLOCK、slave_parallel_workers=8（建议 4-16，不要超过从库 CPU 核数）、slave_preserve_commit_order=ON 保证提交顺序。MySQL 8.0 还可以设置 binlog_transaction_dependency_tracking=WRITESET，冲突检测更细，并行度更高。

从库放宽持久化：innodb_flush_log_at_trx_commit=2、sync_binlog=0；不做级联复制时设 log_slave_updates=OFF，能明显减少从库写盘压力。

拆大事务：把 10 万行的批量更新拆成每批 500-1000 行提交，单个事务的 binlog 建议控制在 100MB 以内。

架构上如何自动屏蔽延迟大的从库？

结论：读流量不能无脑轮询，必须按延迟动态路由，延迟超过阈值的从库自动摘除。

常规做法是在中间件层（ShardingSphere-Proxy、ProxySQL、MyCat 等）定时采集各从库的延迟指标，路由时过滤掉延迟超过 1 秒的实例，只把请求发给延迟达标的从库。

同时要把读流量分层：在线读走低延迟从库，报表、日志、离线分析类查询走单独的从库或数仓，不要让它们和在线读抢同一个实例。只保留 1-2 个从库承担强一致读，剩下的用于分摊普通读。

怎么准确监控主从延迟？

结论：Seconds_Behind_Master 不可信，生产环境应该用 pt-heartbeat。

原因是这个值算的是"从库 SQL 线程当前回放的事件时间戳与系统时间的差"：从库 SQL 线程空闲时它显示 0，主库长时间无写入时它也显示 0 甚至为 NULL，会把真实的落后状态掩盖掉。

pt-heartbeat 的做法是让主库每隔 1 秒向一张心跳表写当前时间戳，从库读出后与本地时间对比，误差可达毫秒级。启动命令形如 pt-heartbeat --update -D heartbeat --host=主库地址 --interval=1。同时配合 SHOW SLAVE STATUS 观察 Relay_Master_Log_File 与 Exec_Master_Log_File 的差值，或者 GTID 的 Retrieved 与 Executed 差值，作为交叉验证。

总结一下：主从延迟靠"消灭"是做不到的，靠分层处理才可行——怕延迟的读强制走主库，数据库层用半同步加并行回放把延迟压到毫秒级，路由层按延迟自动摘除慢从库，监控用 pt-heartbeat 而不是 Seconds_Behind_Master。这四件事都做到位，读写分离才算真正可用。