Last_SQL_Error为空但Slave_SQL_Running为NO，常见于STOP SLAVE显式执行、sql_slave_skip_counter未重置、relay_log_recovery=ON时relay log文件缺失，或GTID模式下GTID空洞导致SQL线程静默停止。
MySQL主从复制中Last_SQL_Error为空但Slave_SQL_Running为NO的常见原因
这通常不是数据损坏或网络中断导致的“典型失败”，而是复制线程因非错误性状态主动退出——最常见的是STOP SLAVE被显式执行，或SQL线程遇到SET GLOBAL sql_slave_skip_counter后未重置就继续运行，触发安全终止。此时SHOW SLAVE STATUS里Last_SQL_Error保持空字符串，但Seconds_Behind_Master变为NULL，Slave_SQL_Running为NO。
如何快速定位是否是人为停止或隐式中断
直接查SHOW SLAVE STATUS\G中的两个关键字段：
-
Slave_SQL_Running_State如果是Slave has read all relay log; waiting for more updates，说明SQL线程其实正常；但若显示Has stopped或为空，则大概率是被停过 -
Retrieved_Gtid_Set和Executed_Gtid_Set是否相等？不等 + SQL线程停着，说明relay log没消费完，但SQL线程卡在某个位置没报错——常见于启用了relay_log_recovery=ON但缺失relay log文件时，SQL线程拒绝启动且不写错误 - 检查
mysql.err日志末尾有没有Stopping slave SQL thread或Skipping transaction because of sql_slave_skip_counter这类提示
relay_log_recovery=ON开启时SQL线程静默停止的处理方式
这是最容易被忽略的“无错停止”场景：MySQL重启后，若relay_log_recovery=ON，它会尝试重建relay log，但若原relay-log.info指向的relay log文件已被轮转删除（比如relay-bin.000012不存在），SQL线程将直接放弃启动，Last_SQL_Error留空，Slave_SQL_Running设为NO，且不报任何警告。
- 验证方法：
ls -l查看datadir下是否存在relay-bin.*中Relay_Log_File字段所指的文件 - 临时恢复：关闭
relay_log_recovery（需重启mysqld），再START SLAVE - 长期方案：确保
relay_log_purge=ON且relay_log_space_limit足够，避免手动清理relay log；或改用MASTER_AUTO_POSITION=1+ GTID，绕过relay log文件路径依赖
GTID模式下Executed_Gtid_Set不连续却无错误的特殊情况
当从库执行了SET GTID_NEXT='xxx'; BEGIN; COMMIT;这类人工注入事务，或跳过事务后未及时SET GTID_NEXT='AUTOMATIC'，会导致GTID集合出现空洞。SQL线程在遇到下一个期望GTID时发现已存在（因为被跳过或伪造），就会静默停止——Last_SQL_Error为空，Slave_SQL_Running变NO，但Retrieved_Gtid_Set仍持续增长。
- 检查命令：
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;看APPLIER_STATE是否为ERROR或OFF - 修复步骤：先
STOP SLAVE，再SET GTID_NEXT='AUTOMATIC'，然后START SLAVE - 预防：禁用
sql_log_bin=0下的GTID事务注入；审计DBA操作日志中是否含SET GTID_NEXT
真正难排查的，往往是那些“没报错”的情况——因为日志不记、状态不显、监控不告警。重点盯住Relay_Log_File是否存在、Executed_Gtid_Set是否连续、以及relay_log_recovery这个开关是否在你不知情时起了作用。
