Seconds_Behind_Master不可信，应重点监控Master_Log_File/Read_Master_Log_Pos（IO位点）与Relay_Master_Log_File/Exec_Master_Log_Pos（SQL位点）四者关系，结合GTID差值和pt-heartbeat验证真实延迟。
看 SHOW SLAVE STATUS\G 的四个位点，别信 Seconds_Behind_Master
Seconds_Behind_Master 经常失真：主从时钟不同步、SQL线程卡在大事务中间、IO线程断连重试时，它可能显示 0 或 NULL，但实际已落后几万行。真正可信的是这四个字段的组合关系：
-
Master_Log_File和Read_Master_Log_Pos：IO线程拉到哪了 -
Relay_Master_Log_File和Exec_Master_Log_Pos：SQL线程执行到哪了
对比逻辑很简单：
- 若
Master_Log_File ≠ Relay_Master_Log_File，或Read_Master_Log_Pos明显 Exec_Master_Log_Pos → IO线程没拉全，问题在传输层 - 若
Relay_Master_Log_File == Master_Log_File且Exec_Master_Log_Pos → relay log已收齐，但SQL线程回放慢，这是最常见根因
查 SHOW PROCESSLIST 确认两个线程是否真在干活
仅看 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 不够，它们可能卡在非活跃状态：
-
IO_THREAD（system user行）状态应为Queueing master event to the relay log或Waiting for master to send event；若长期是Connecting to master，说明网络不通或主库binlog_dump线程卡住 -
SQL_THREAD状态应为Reading event from the relay log或Executing event；若停在Waiting for table metadata lock、Waiting for commit lock或Updating超过30秒，基本就是DDL或大事务阻塞 - 注意
Time列：如果数值持续上涨（比如从120升到300），而State不变，说明SQL线程被锁死或正在回放一个超长事务
用 INFORMATION_SCHEMA.INNODB_TRX 找大事务和锁等待
从库SQL线程单线程回放，一个大事务就能堵死整条流水线。重点查：
-
trx_state = 'RUNNING'（不是LOCK WAIT）且trx_started时间远早于当前时间 → 长事务未提交 -
trx_rows_modified > 100000→ 大事务嫌疑极高；超过200万基本可锁定为批量导入或分表操作 -
trx_operation_state是inserting或updating，且持续数分钟以上 → 正在回放中，但进度极慢
这类事务不会出现在 SHOW PROCESSLIST 的普通用户会话里，只在 INNODB_TRX 中暴露。
验证并行复制是否真生效，而不是参数开了就等于提速
MySQL 5.7+ 开了 slave_parallel_workers > 0 不代表并行一定跑起来。必须同时满足：
- MySQL 5.7：
slave_parallel_type = LOGICAL_CLOCK且主库binlog_group_commit_sync_delay > 0 - MySQL 8.0+：
slave_parallel_type = LOGICAL_CLOCK或COMMIT_ORDER，且slave_preserve_commit_order = ON - 主库
binlog_format必须是ROW；STATEMENT格式下并行度几乎为零
验证方法很直接：执行 SHOW PROCESSLIST，如果只看到一个 SQL Thread，哪怕 slave_parallel_workers = 8，也说明条件不满足，退化成单线程了。
最容易被忽略的一点：延迟不是“现象”，而是“结果”。它背后可能是磁盘IO打满、MDL锁卡住、跨机房带宽饱和、甚至从库内存配置只有主库一半。定位时别只盯着SQL线程，先确认 Relay_Master_Log_File 和主库 SHOW MASTER STATUS 的文件名是否一致——如果差了4个binlog文件，那根本不用查SQL，IO链路已经断在半路了。
