slave_sql_running: no 表示sql线程已初始化但未执行，常见于gtid位点不一致、slave_relay_log_info表错误或事务回滚未清理；此时last_sql_error为空，需检查该表内容、gtid集合及错误日志，优先执行reset slave all而非跳过事件。
Slave SQL thread initialized but not running 是什么状态
这表示 SQL 线程已加载、位点信息已读取，但实际未开始执行中继日志（relay log）里的事件。它不是“崩溃退出”，而是卡在初始化后、执行前的某个校验或等待环节——常见于 GTID 模式下位点不一致、slave_relay_log_info 表残留错误位置、或事务回滚未清理干净。
为什么 show slave status\G 看不到 Last_SQL_Error
因为线程根本没走到“执行 SQL”那一步，错误还没发生。此时 Slave_SQL_Running 是 No，但 Last_SQL_Error 为空或为 NULL，不能靠它定位问题。
-
Relay_Log_File和Relay_Log_Pos显示的是 SQL 线程准备从哪读，不是它实际卡在哪 - 真正关键的是
slave_relay_log_info表内容，它由 SQL 线程启动时直接读取，若该表里存了已删除表对应的drop table位置，线程就会停在那儿不动 - GTID 模式下还要核对
Executed_Gtid_Set和Retrieved_Gtid_Set是否有空洞或冲突
检查错误日志必须带 --verbose 和明确路径
MySQL 默认不把复制线程初始化细节写进错误日志，除非你主动开启调试级输出。光看 log_error 配置的文件（比如 /var/log/mysql/error.log）往往只有“Starting replication threads”，没有“Why it stopped before running”。
- 临时启用详细日志：在启动 mysqld 时加参数
--log-error-verbosity=3，并确认log_error变量指向可读文件：SELECT @@log_error; - 更直接的办法是查错误日志里是否出现
SQL thread: starting或SQL thread: initializing from relay log后立即中断的记录 - 如果日志里有类似
Could not find first log file name in binary log index file或Failed to initialize the master info structure，说明位点元数据损坏，不是 SQL 执行错误
绕过初始化卡死最稳妥的实操路径
别急着 SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1 ——这个只跳过一条 event，对“根本没开始执行”的情况无效，反而可能让位点彻底错乱。
- 先停掉复制：
STOP SLAVE; - 清空所有位点状态：
RESET SLAVE ALL;（注意：5.6+ 支持ALL，会删slave_relay_log_info表和 relay log 文件） - 如果是 GTID 模式，再补一句：
SET GLOBAL gtid_purged = 'xxx';（值来自主库SHOW MASTER STATUS的Executed_Gtid_Set） - 重新配置主从连接：
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1;（GTID）或指定MASTER_LOG_FILE/MASTER_LOG_POS（非 GTID） - 最后
START SLAVE;，观察Seconds_Behind_Master是否从NULL变成递减数字
真正容易被忽略的是：重置后 relay log 文件名会重置为 localhost-relay-bin.000001，但旧的 .index 文件可能还残留，导致下次启动又读错——所以 RESET SLAVE ALL 必须配合手动 rm -f /var/lib/mysql/localhost-relay-bin.*（路径以 relay_log 变量为准）。
