Slave_IO_Running为No或Connecting说明网络/权限问题，为Yes但Seconds_Behind_Master上涨则卡在SQL线程回放；GTID差值、pt-heartbeat和performance_schema可精准定位大事务阻塞。
看 SHOW SLAVE STATUS\G 的 Slave_IO_Running 和 Seconds_Behind_Master 组合状态
真正卡在网络还是卡在回放，第一眼就能区分。如果 Slave_IO_Running 是 No 或者 Connecting to master，基本就是网络或主库权限/端口问题；如果它是 Yes，但 Seconds_Behind_Master 持续上涨，说明 binlog 已拉回本地，问题出在从库 SQL 线程执行环节。
特别注意：当 Seconds_Behind_Master 显示为 0 但实际有延迟（比如刚执行完一个大事务），Retrieved_Gtid_Set 和 Executed_Gtid_Set 的差值会暴露真实积压——前者是已取回的 GTID，后者是已执行的 GTID，差得越多，越可能是大事务堵在 relay log 里没跑完。
用 mysqlbinlog 定位大事务起止位置
从库卡住时，最直接的办法是去主库查对应时间段的 binlog，确认有没有超长事务。重点不是看 SQL 写得多不多，而是看事务跨度有多大：
-
mysqlbinlog --no-defaults --base64-output=decode-rows -v --start-datetime="2026-07-01 15:30:00" mysql-bin.000012—— 解析指定 binlog 文件中某一时段内容 - 找
### BEGIN和紧随其后的### COMMIT之间是否夹着成千上万行### UPDATE/### DELETE - 留意事务内是否有跨表、跨索引扫描，或者带
WHERE条件但没走索引的语句（这类在从库回放时极易锁表或慢）
如果发现某个事务从 begin 到 commit 跨越数秒甚至几十秒，那它大概率就是罪魁祸首——MySQL 5.7+ 的并行复制（MTS）对单一大事务依然串行回放。
对比 SHOW PROCESSLIST 和 performance_schema.events_statements_current
登录从库后别只盯着 SHOW PROCESSLIST，它只能看到当前正在跑的线程。而真正卡住的 SQL 可能已经进入执行阶段但还没完成，这时候需要查性能字典表：
SELECT * FROM performance_schema.events_statements_current WHERE THREAD_ID IN (SELECT THREAD_ID FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_COMMAND = 'Query') ORDER BY TIMER_START DESC LIMIT 1;- 重点关注
SQL_TEXT字段是否和你从 binlog 里抓到的大事务一致，以及TIMER_WAIT是否异常高（单位是皮秒，换算成秒要除以 10^12） - 如果该 SQL 的
STATE是executing且TIMER_WAIT持续增长，基本锁定是执行层瓶颈，不是网络问题
网络问题通常不会让 SQL 线程停留在 executing 状态，而是会让 IO 线程卡在 Waiting for master to send event 或反复重连。
用 pt-heartbeat 验证真实延迟而非依赖 Seconds_Behind_Master
Seconds_Behind_Master 在大事务、DDL、SQL 线程阻塞时完全失效——它只计算 relay log 中最后一条事件的时间戳与当前系统时间的差，不反映实际数据一致性。所以线上必须部署 pt-heartbeat：
- 在主库定时写入心跳记录：
pt-heartbeat --update --database=test --table=heartbeat --host=master_ip --user=user --password=pass - 从库查延迟：
pt-heartbeat --check --database=test --table=heartbeat --host=slave_ip --user=user --password=pass - 如果
pt-heartbeat报出 8 秒延迟，而Seconds_Behind_Master显示 0，那几乎可以断定：SQL 线程正卡在一个未提交事务里，或者被 MDL 锁阻塞
这个差异本身就是一个关键信号：网络通畅，但从库执行不动。这时候再回头翻 binlog 和 performance_schema，效率高得多。
