主从延迟超过秒级，先查 Seconds_Behind_Master
是否真延迟
很多情况下
Seconds_Behind_Master显示非 0，但实际是误报：比如从库 SQL 线程空闲、IO 线程刚拉完日志还没开始执行，或主库无写入时该值可能抖动。真正要关注的是持续 > 5 秒且不断增长的延迟。
确认方式：
- 登录从库执行
SHOW SLAVE STATUS\G，重点看
Seconds_Behind_Master、
SQL_Delay（是否人为设了延迟）、
Slave_SQL_Running_State（如卡在 “Reading event from the relay log” 说明 SQL 线程慢）；
- 同时对比主从的
SHOW MASTER STATUS和
SHOW RELAYLOG EVENTS，看 relay log 是否已追平 master log position。
常见误判点：
- 主库启用
binlog_format=STATEMENT且含非确定函数（如
NOW()、
UUID()），导致从库重放结果不一致，SQL 线程可能重试或卡住
- 从库开启了
read_only=1但有 super 权限用户执行了写操作，破坏了复制一致性，触发校验失败后停同步
从库单线程回放瓶颈明显，考虑升级到基于 GTID 的并行复制
MySQL 5.6+ 默认 SQL 线程是单线程的，即使主库并发高，从库也只能串行执行 relay log 中的事务——这是延迟最常见根源。
开启并行复制的关键配置：
-
slave_parallel_type=LOGICAL_CLOCK（推荐，比 DATABASE 更细粒度）
-
slave_parallel_workers=4（建议设为 CPU 核数的 70%，避免上下文切换开销）
- 必须启用 GTID：
gtid_mode=ON+
enforce_gtid_consistency=ON
注意：
- 并行复制只对
binlog_format=ROW有效，STATEMENT 模式下事务间依赖难判定，无法安全并行
- 如果主库存在大事务（如单个
UPDATE影响百万行），它仍会独占一个 worker，拖慢整体进度
- 查看并行效果：监控
performance_schema.replication_applier_status_by_coordinator表中的
WORKERS数和
APPLYING_EVENT状态
主库写入突增或从库 I/O 负载高，检查 relay log 刷盘与磁盘性能
relay log 写入慢、刷盘阻塞，会导致 IO 线程跟不上主库节奏，进而拖累整个复制链路。
实操排查项：
- 检查从库
sync_relay_log=10000（默认值），值太小（如 1）会频繁 fsync，拖慢 IO 线程；太大（如 0）则宕机可能丢 relay log
- 确保 relay log 存放在独立、低延迟磁盘（避开系统盘或主库数据盘），用
relay_log=/data/mysql/relay-bin显式指定路径
- 观察
iostat -x 1中从库磁盘的
%util和
await，若长期 >90% 或 await >20ms，说明磁盘已成瓶颈
- 避免在从库执行大查询：全表扫描、未走索引的 JOIN 会大量读取 buffer pool，挤占 IO 带宽，间接影响 relay log 读取速度
业务层写入不合理，直接放大复制压力
很多延迟问题根源不在 MySQL 配置，而在应用写法。例如批量插入用 1000 条
INSERT ... VALUES (...),(...),...是高效的；但若拆成 1000 个单行
INSERT，就会产生 1000 个 binlog event，极大增加网络传输、解析、回放开销。
典型高危写法：
- 在循环中逐条
UPDATE同一张表的多行（应改用
INSERT ... ON DUPLICATE KEY UPDATE或临时表 JOIN）
- 使用
SELECT ... FOR UPDATE+ 应用层判断再更新，导致锁等待传导到从库（从库虽不加锁，但事务顺序必须严格一致）
- 主库执行
ALTER TABLE大表（尤其未用
ALGORITHM=INPLACE），会生成巨量 binlog，从库回放耗时极长
可落地优化：
- 对写密集场景，主库开启
binlog_row_image=MINIMAL（5.6.2+），减少 ROW 格式下 binlog 体积
- 从库设置
innodb_flush_log_at_trx_commit=2（牺牲极小安全性换回放速度，仅适用于非金融类场景）
- 关键业务表加
innodb_autoinc_lock_mode=2，避免自增锁阻塞主库并发插入
延迟不是孤立指标，它暴露的是主从链路中任意一环的短板：可能是主库日志生成太快，也可能是从库磁盘太慢，还可能是某条慢查询把 SQL 线程堵死了。定位时别只盯着
Seconds_Behind_Master，得顺着 IO 线程 → relay log → SQL 线程 → 应用写法这条链路一节节敲过去。
