主从延迟超10秒属异常，需排查线程状态、gtid差值及sql线程卡顿；seconds_behind_master易失真，应结合retrieved_gtid_set与executed_gtid_set差值、processlist及iostat等综合判断根因。
主从延迟超过 10 秒，基本可以断定不是偶发抖动，而是架构或配置层面存在硬伤。单纯重启复制线程或调小 sync_binlog 只会掩盖问题，甚至引发数据丢失。
怎么看延迟是不是真高？别只盯 Seconds_Behind_Master
这个值在很多场景下是“假低”或“假高”，尤其当从库 SQL 线程卡住、IO 线程中断、或者主库时间不同步时，它可能显示为 NULL 或错误的 0。
- 先确认线程状态：
Slave_IO_Running和Slave_SQL_Running必须都为Yes - 检查
Retrieved_Gtid_Set和Executed_Gtid_Set的差值——这才是真实积压的事务数，比秒数更可靠 - 如果
Seconds_Behind_Master是 0，但Executed_Gtid_Set长期不更新，说明 SQL 线程实际已 hang 住（常见于锁等待、大事务回放阻塞） - 用
SHOW PROCESSLIST查看从库上system user的 SQL 线程正在执行哪条语句，是否处于Updating、Locked或Waiting for table metadata lock
为什么启用 slave_parallel_workers 后延迟反而更严重？
并行复制不是开个开关就万事大吉。MySQL 的并行策略依赖事务间无冲突，一旦误判，就会触发协调机制退化成单线程，甚至因冲突重试导致延迟翻倍。
-
slave_parallel_type=DATABASE（默认）只对跨库写入有效；如果所有业务都写同一个库，等于没开 -
slave_parallel_type=LOGICAL_CLOCK要求主库开启binlog_transaction_dependency_tracking=WRITESET，否则从库无法识别事务依赖关系 -
slave_parallel_workers值设得过大（比如 > CPU 核数 × 2），会导致线程争抢 buffer pool 和磁盘 IO，反而拖慢整体回放 - 检查
SHOW SLAVE STATUS中的Seconds_Behind_Master和Slave_SQL_Running_State是否频繁在 “Waiting for dependency” 和 “Executing event” 之间切换
大事务回放卡死，怎么快速定位和拆解？
一个未提交的 500 万行 DELETE 在主库只花 2 秒，但在从库可能卡住 20 分钟——因为从库要逐行回放 ROW 格式 binlog，并且每行都走索引查找 + 锁 + 写 redo。
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v relay-bin.0000xx | head -n 200查看当前正在回放的 relay log 文件开头，找最长的### INSERT/UPDATE/DELETEblock - 重点排查：没有主键或唯一索引的表、分区表上的 DML（尤其是存储过程中执行的）、
WHERE条件走不到高效索引的语句 - 临时止损：在从库执行
STOP SLAVE; SET GLOBAL slave_skip_errors = '1062,1032'; START SLAVE;跳过重复键或找不到行的错误（仅限紧急恢复，事后必须核对数据） - 长期方案：主库禁止在业务高峰期执行 > 10 万行的 DML；改用
LIMIT分批 +COMMIT，并在应用层加 sleep 避免压垮从库
网络和硬件瓶颈常被忽略，但往往是根因
很多团队花两周调参数，最后发现是跨机房千兆网卡跑满、或者从库还在用 SATA SSD 做中继日志盘。
- 用
iperf测主从间 TCP 吞吐：如果持续低于主库Binlog_cache_use每秒写入量（可通过SHOW GLOBAL STATUS LIKE 'Binlog_cache%'计算），就是带宽瓶颈 - 检查从库磁盘 IO：用
iostat -x 1观察%util是否长期 > 90%，await是否 > 20ms——这说明磁盘已成瓶颈，NVMe 是刚需 -
relay_log_info_repository=TABLE+relay_log_recovery=ON必须开启，否则从库异常重启后会重放全部 relay log，延迟雪上加霜 - 从库
innodb_buffer_pool_size至少为主库的 1.2 倍——主库热数据少，但从库要同时服务读请求 + 回放，缓存压力更大
真正棘手的延迟往往不是单一因素，而是“大事务 + 单线程回放 + SATA 磁盘 + 跨机房网络”四者叠加。先停掉可疑大作业，再查 PROCESSLIST 和 iostat，比直接改 slave_parallel_workers 有效得多。
