如何解决MySQL主从架构中Slave_SQL_Running为No的情况？

Slave_SQL_Running: No 说明 SQL 线程卡在不可重放语句上，必须先查 Last_SQL_Error 定位错误码（如1032/1062），再针对性修复：1032需补数据，1062需删冗余，RBR下跳过风险高，GTID模式须用空事务跳过，严禁配置 slave_skip_errors=all。

Slave_SQL_Running: No 说明 SQL 线程卡在某条语句上，不是网络或权限问题，而是数据或语句本身不可重放。必须先看 Last_SQL_Error，再决定删数据、跳过，还是回滚修复。

查 Last_SQL_Error 定位错误码和上下文

这是所有操作的起点。执行 SHOW SLAVE STATUSG 后，直接盯住 Last_SQL_Error 字段——它比 Seconds_Behind_Master: NULL 或 Relay_Log_Pos 停滞更有诊断价值。

1. 常见错误码：1062（主键/唯一键重复）、1032（记录不存在）、1418（函数创建不安全）、1050（表已存在）
2. 注意错误信息里的坐标：master log mysql-bin.0000xx, end_log_pos 123456，这是后续用 mysqlbinlog 解析的关键位置
3. RBR 模式下错误信息常不带具体 SQL，仅提示事务失败；此时必须解析 binlog，不能只靠错误文本猜

区分 1062 和 1032：删还是补？别反着来

这两类错误看似都是“数据不一致”，但成因相反，处理方向完全相反。

1. 对 1062（Duplicate entry）：大概率是从库多了一条不该有的记录。先确认主库是否真没这条数据：SELECT * FROM table_name WHERE id = X；若主库无结果，从库有，则执行 DELETE FROM table_name WHERE id = X，再 START SLAVE
2. 对 1032（Can't find record）：大概率是从库少了一条该有的记录。先查主库 binlog：mysqlbinlog --base64-output=decode-rows -v mysql-bin.0000xx | grep -A 10 -B 10 "X"，确认主库是否真执行了 INSERT；若主库有、从库无，需从备份恢复该行，或用 mysqlbinlog 回放缺失事件
3. 盲目 SET GLOBAL sql_slave_skip_counter = 1 对 1032 风险极高——跳过的是“删不存在的记录”，等于把本该删的数据留在从库，后续可能引发更严重的冲突

跳过错误要分场景：临时跳 vs 配置级跳 vs GTID 下跳

跳过不是修复，是绕开。不同场景下可靠性和副作用差异极大，选错等于埋雷。

1. sql_slave_skip_counter 只在 SBR 模式下行为可预测；RBR 下它可能跳过半个事务，导致主从数据逻辑分裂
2. slave_skip_errors=1062,1032 是配置项，写进 /etc/my.cnf 的 [mysqld] 段，重启生效；但 slave_skip_errors=all 绝对禁止用于生产环境
3. GTID 模式下 sql_slave_skip_counter 完全失效。必须用 SET GTID_NEXT='xxx-yyy-zzz:1'; BEGIN; COMMIT; 插入空事务，再 SET GTID_NEXT='AUTOMATIC'；否则 START SLAVE 会报错
4. 跳完务必验证：SELECT @@global.gtid_executed; 和 SELECT @@global.gtid_purged; 是否合理推进，避免 GTID 集合断层

权限变更、系统表操作引发的隐性中断

这类错误不会立刻报错，但会导致后续连接静默失败或复制逻辑错乱，极难排查。

1. 直接 UPDATE mysql.user 修改账号，会被原样重放到从库；若从库用户不存在或 host 不匹配，就卡在 1032 或 1045，且错误日志里不提示“权限”二字
2. 正确做法是用 ALTER USER（MySQL 5.7+），它被标记为复制安全语句；或停掉 SQL 线程后，在从库手动同步，并确保 SET sql_log_bin = 0
3. CREATE FUNCTION / PROCEDURE 若带 DETERMINISTIC 或 READS SQL DATA 缺失声明，会触发 1418 错误；修复方式是加声明后重建，而非跳过
4. 任何对 mysql 库的 DML 操作，都建议提前在从库关掉 replicate_ignore_db=mysql（如果开了），否则可能漏同步关键元数据

真正容易被忽略的是：SQL 线程卡住时，Relay_Log_Space 仍在增长，说明 IO 线程还在拉日志，但 SQL 线程死锁在某个事务里不动——这种情况下，STOP SLAVE; START SLAVE 完全无效，必须定位到具体事务并干预其执行位置。