Exec_Master_Log_Pos卡住但Seconds_Behind_Master不为0，说明SQL线程存活但执行停滞，根本原因是回放层被大事务、DDL或元数据锁阻塞；需重点检查Slave_SQL_Running_State状态、主库活跃大事务及中继日志对齐性。
Exec_Master_Log_Pos卡住但Seconds_Behind_Master不为0
这说明SQL线程没死，但根本没推进执行位置——不是网络或IO问题，是回放层被堵死了。别急着重启，先确认Slave_SQL_Running_State是不是卡在Waiting for table metadata lock、altering table或Waiting for dependent transaction to commit这类状态。只要它停在这些状态超过1分钟，基本就是SQL线程被锁或大事务拖住。
常见干扰项：
-
Seconds_Behind_Master持续上涨但Exec_Master_Log_Pos不动 → 90%是大事务或DDL阻塞 -
Relay_Log_Space还在涨 → IO线程照常写relay log，进一步印证是SQL线程单点卡死 -
Last_SQL_Error为空 ≠ 没问题，它只记录“执行失败”，不记录“卡住等待”
查主库有没有活跃大事务
从库卡住，根子往往在主库。直接连主库查：SELECT trx_id, trx_started, trx_rows_modified, trx_state FROM information_schema.INNODB_TRX WHERE trx_rows_modified > 10000 AND trx_started
如果返回结果，尤其是trx_state = RUNNING且trx_rows_modified几十万以上，基本就是它了。注意：不是所有大事务都会立刻触发复制延迟，但一旦它提交，从库SQL线程就得单线程扛完全部变更，期间Exec_Master_Log_Pos必然冻结。
补充判断点：
- 对比主库
SHOW MASTER STATUS的Position和从库Read_Master_Log_Pos：如果两者接近，说明binlog已传全，问题纯属从库回放不过来 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析Relay_Master_Log_File+Exec_Master_Log_Pos附近事件，看是否正卡在一个超长UPDATE或DELETE上
DDL正在执行或被元数据锁阻塞
DDL是Exec_Master_Log_Pos不动的高频原因。两种典型表现：
-
Slave_SQL_Running_State = altering table→ DDL正在执行，单线程应用，必须等完 -
Slave_SQL_Running_State = Waiting for table metadata lock→ 从库有长事务或慢查询占着表，新DDL进不来
查阻塞源（从库执行）：SELECT * FROM performance_schema.threads WHERE PROCESSLIST_COMMAND = 'Query' AND PROCESSLIST_STATE LIKE '%metadata%'; 或更直接：SELECT blocking_trx_id, waiting_trx_id FROM performance_schema.data_lock_waits;
别直接KILL疑似会话——先看INFORMATION_SCHEMA.INNODB_TRX里哪个事务trx_started最早、trx_state是LOCK WAIT，再针对性干掉。
relay_log_recovery没生效或中继日志损坏
MySQL重启后Exec_Master_Log_Pos卡住不动，很可能是中继日志加载错位。先确认配置是否真生效：SHOW VARIABLES LIKE 'relay_log_recovery'; 必须返回ON，且relay_log_info_repository在5.7+必须是TABLE（不能是FILE）。
若已损坏，切勿手动删*-relay-bin.*或relay-log.index——正确做法是：
STOP SLAVE;RESET SLAVE;- 用
SHOW SLAVE STATUS\G里的Relay_Master_Log_File和Exec_Master_Log_Pos重设起点：CHANGE MASTER TO RELAY_LOG_FILE='xxx', RELAY_LOG_POS=yyy; START SLAVE;
这个操作看似重置，实则是在修复relay log与master binlog的对齐关系。很多团队跳过这步直接调参，结果延迟反复出现——因为底层日志链已经断了。
