主从延迟需综合判断：先看Seconds_Behind_Master，再比对Read_Master_Log_Pos与Exec_Master_Log_Pos差值及主库binlog位置；长期＞60秒且差值扩大表明存在同步瓶颈。
主从延迟怎么看：先确认是不是真延迟
MySQL 主从延迟不是靠感觉，得看 Seconds_Behind_Master，但它可能不准——比如 IO 线程卡住时会显示 0，实际已经落后。更可靠的方式是结合 SHOW SLAVE STATUS\G 中的 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 差值，再比对主库当前 binlog 位置（SHOW MASTER STATUS），确认真实落差。
- 如果
Seconds_Behind_Master是NULL，说明 SQL 线程已停止，先查Slave_SQL_Running_State和错误日志 - 如果值长期 > 60 秒，且差值持续扩大，基本可判定存在同步瓶颈
- 单次大事务（如
DELETE FROM huge_table WHERE ...）会导致该值“跳变式”飙升，不是持续性问题，但会影响监控判断
写入密集场景下如何降低从库回放压力
MySQL 5.7+ 支持并行复制，但默认只按库（slave_parallel_type = DATABASE）分发，效果有限。改成按逻辑时钟（LOGICAL_CLOCK） + 合理设置线程数（slave_parallel_workers = 8~16）能明显提升回放速度，前提是主库开启了 binlog_transaction_dependency_tracking = WRITESET（推荐）或 COMMIT_ORDER。
- 必须确保主库
binlog_format = ROW，STATEMENT 模式下无法使用 writeset -
slave_parallel_workers不宜设得过高，超过 CPU 核心数后反而因调度开销导致性能下降 - 避免在从库执行长查询或锁表操作，会阻塞 SQL 线程，间接拉高延迟
大事务是延迟元凶：怎么识别和拆解
主库上一个耗时 30 秒的 UPDATE，从库可能要花 5 分钟回放——因为单线程串行执行，且无法中断。可通过慢日志（long_query_time = 1）配合 pt-query-digest 找出高频大事务；也可在主库开启 binlog_rows_query_log_events = ON，让从库日志里带原始 SQL，方便定位。
- 在应用层拆分大更新：比如用
WHERE id BETWEEN ? AND ?分页更新，每次 1k 行，加SLEEP(0.1)控制节奏 - 避免在业务高峰期执行
ALTER TABLE ... ADD INDEX类 DDL，这类操作在从库也需重放，且会锁整个表 - 对于归档类清理任务，考虑用
pt-archiver替代直接DELETE，它天然支持分块和限流
网络与硬件层面容易被忽略的瓶颈
主从间网络抖动、丢包、高延迟（如跨机房部署）会让 IO 线程频繁重传，表现为 Master_Host 连接不稳定、Seconds_Behind_Master 波动剧烈。此时 slave_net_timeout（默认 60 秒）和 master_connect_retry（默认 60 秒）设置不合理会加剧问题。
- 把
slave_net_timeout调小到 30，master_connect_retry设为 10，加快异常连接恢复速度 - 从库磁盘 I/O 能力弱于主库（比如主库用 NVMe，从库还是 SATA 盘），会导致 relay log 写入慢、SQL 回放卡顿，
iostat -x 1可验证%util是否长期 > 90% - 不要在从库挂载低性能存储（如 NFS）存 relay log，必须本地 SSD
主从延迟的本质是“单点写入 vs 多点消费”的失衡，优化永远要从主库源头控量、从库侧提并发、链路中保稳定三方面一起动手，光调参不改逻辑，迟早又回到原点。
