要查主库或从库是否存在“正在跑”的大事务，需查INFORMATION_SCHEMA.INNODB_TRX表，重点筛选trx_state = 'RUNNING'、trx_started远早于当前时间、trx_rows_modified > 100000（超200万行属高风险）、trx_operation_state为updating/deleting，且SHOW PROCESSLIST中SQL线程Time持续增长。
看INFORMATION_SCHEMA.INNODB_TRX里有没有“正在跑”的大事务
主库上刚提交的大批量UPDATE或DELETE，在从库回放时不是“快照”，而是逐行重放——只要它还没执行完，Seconds_Behind_Master就会持续跳涨。真正要盯的是从库当前是否正卡在这个事务里：
-
trx_state = 'RUNNING'（不是LOCK WAIT）且trx_started时间远早于现在 → 说明它已在执行中，且没被锁住，只是本身太重 -
trx_rows_modified > 100000→ 基本可判定为高风险事务；超过 200 万行，大概率就是分表、归档、清理类操作 -
trx_operation_state显示updating或deleting，且Time列在SHOW PROCESSLIST里持续增长 → SQL 线程正卡在这一条语句上，后续所有事件全在排队
比对Relay_Master_Log_File和主库SHOW MASTER STATUS的文件差
只看Seconds_Behind_Master容易误判：它可能因主从时钟不同步、事务未提交而失真。真实落后量得靠日志位置算：
- 从库执行
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File和Exec_Master_Log_Pos - 主库执行
SHOW MASTER STATUS，拿到File和Position - 若文件名不同（比如从库还在处理
mysql-bin.003731，主库已写到mysql-bin.003735）→ 落后至少 4 个 binlog 文件，基本排除网络问题，根因在 SQL 回放层 - 若文件相同，但
Exec_Master_Log_Pos比主库Position小几十万甚至上百万 → 正在回放一个巨量变更，延迟会随该事务执行时间线性增长
查SHOW PROCESSLIST里system user那两行的状态
从库有两个关键后台线程，它们的状态比任何指标都直接：
-
IO_THREAD的State如果是Queueing master event to the relay log或Waiting for master to send event→ IO 正常，问题不在传输 -
SQL_THREAD的State如果是Updating、Deleting或Executing event，且Time值稳定在 30 秒以上 → 它正在回放一个长耗时语句，不是卡在锁，就是单事务数据量过大 -
State是Waiting for table metadata lock或Waiting for commit lock→ 大概率是主库刚做完ALTER TABLE，从库还没拿到元数据锁，整个复制链路被堵死
用pt-heartbeat或自建心跳表验证实际延迟
Seconds_Behind_Master本质是基于主从系统时间差的估算，跨机房、NTP 不稳、GTID 模式下都可能严重偏移。更可靠的方式是实测：
- 部署
pt-heartbeat，在主库每秒写入一行带时间戳的心跳记录，从库读取并计算差值 → 这个值反映的是端到端真实延迟 - 或手动建一张
heartbeat表，主库用INSERT ... ON DUPLICATE KEY UPDATE ts=NOW()更新，从库查SELECT UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(ts)→ 注意避免从库read_only=ON导致写失败 - 如果
pt-heartbeat显示延迟 5 秒，但Seconds_Behind_Master显示 300 秒 → 基本可断定是大事务导致Exec_Master_Log_Pos长期不动，而SBM还在“乐观估算”
大批量修改的延迟不是“会不会发生”，而是“会卡多久”——关键在事务粒度是否可控。哪怕总行数相同，拆成 100 批每批 1 万行，和单批 100 万行，对从库的压力完全是两个量级。最容易被忽略的是：WRITESET并行复制对单事务完全无效，它只在事务之间调度。
