SQL线程卡住但Seconds_Behind_Master显示为0是典型假象，因该值仅对比Exec_Master_Log_Pos与Read_Master_Log_Pos，而SQL线程停在大事务回滚、锁等待或DDL阻塞时位置未更新，IO线程却持续追入导致“碰巧”相等。
SQL线程卡住但Seconds_Behind_Master显示为0
这是最典型的假象：从库SQL_THREAD实际已停止执行，但复制状态仍显示Seconds_Behind_Master: 0。根本原因是Seconds_Behind_Master只对比Exec_Master_Log_Pos和Read_Master_Log_Pos，而SQL线程停在某个事务里（比如大事务回滚、锁等待、DDL阻塞），Exec_Master_Log_Pos没动，但IO线程还在追，导致两个位置“碰巧”一致。
实操建议：
- 别信
Seconds_Behind_Master，优先查SHOW SLAVE STATUS\G里的Slave_SQL_Running_State——如果卡在Waiting for table metadata lock或executing不动超过1分钟，基本就是SQL线程堵了 - 用
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_COMMAND = 'Query' AND PROCESSLIST_STATE LIKE '%metadata%';定位元数据锁持有者 - 检查
Relay_Log_Space是否持续上涨——它反映的是中继日志文件总大小，比Seconds_Behind_Master更真实
relay_log_recovery=ON没生效导致中继日志损坏
MySQL重启后若未启用relay_log_recovery，可能加载不完整或错位的中继日志，造成SQL线程反复报错Could not parse relay log event entry或直接退出，进而积压。
实操建议：
- 确认配置已写入
my.cnf并重启生效：relay_log_recovery=ON必须搭配relay_log_info_repository=TABLE（5.7+）或relay_log_info_file（5.6），否则无效 - 检查
SHOW VARIABLES LIKE 'relay_log_recovery';返回值是否为ON，不是靠猜 - 若已损坏，不要手动删
relay-log.index或*-relay-bin.*文件——正确做法是STOP SLAVE; RESET SLAVE;再CHANGE MASTER TO ... RELAY_LOG_FILE='xxx', RELAY_LOG_POS=yyy;重设起点
磁盘IO吞吐跟不上relay log写入速度
中继日志本质是顺序写，但若从库磁盘（尤其是系统盘混用）随机IO压力大，或使用机械盘+高并发写入，SQL_THREAD读relay log + IO_THREAD写relay log会争抢IO，表现为iotop -a里mysqld进程%IO长期>90%，SHOW PROCESSLIST中SQL线程状态频繁切换Reading event from the relay log→Waiting for disk I/O。
实操建议：
- 把
relay_log路径单独挂到SSD或专用IO设备上，避开datadir和tmpdir - 调低
sync_relay_log（默认1）——设为100可减少刷盘频率，代价是主从故障时最多丢失100个事件；但别设0，否则崩溃后relay log可能不一致 - 监控
Innodb_buffer_pool_wait_free和Threads_connected，高连接数下buffer pool争抢也会间接拖慢relay log解析
大事务拆分不当引发SQL线程单点阻塞
主库一个UPDATE百万行的事务，在从库会变成一个长耗时操作，期间SQL线程无法处理后续任何事件，relay log持续堆积。即使开了slave_parallel_workers，只要事务没开启GTID或未启用slave_parallel_type=LOGICAL_CLOCK，所有并行线程都会等这个大事务结束。
实操建议：
- 主库侧控制事务粒度：批量更新务必用
LIMIT分页+SLEEP，避免单事务超10秒 - 从库启用并行复制前，先确认
gtid_mode=ON且enforce_gtid_consistency=ON，否则slave_parallel_type=LOGICAL_CLOCK不会真正生效 - 观察
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set差值——若差很多但Seconds_Behind_Master很小，说明并行复制被大事务卡住了
真正麻烦的从来不是日志积压本身，而是积压背后那个没暴露出来的锁、IO瓶颈或配置错位。盯住Slave_SQL_Running_State和Relay_Log_Space，比刷新SHOW SLAVE STATUS看数字有用得多。
