最要紧的是Slave_IO_Running和Slave_SQL_Running两个字段：二者必须均为Yes，任一为No即表示对应线程已停止而非延迟；若异常再查Last_SQL_Errno和Last_SQL_Error定位具体错误原因。
看 SHOW SLAVE STATUS\G 里哪两个字段最要紧
别先翻错误日志，直接登录从库执行 SHOW SLAVE STATUS\G，盯住这两个字段：
-
Slave_IO_Running和Slave_SQL_Running：一个为No就说明线程卡死，不是“慢”，是“停了” -
Last_SQL_Errno和Last_SQL_Error：这才是 SQL 线程真正失败的原因，比如1062（主键冲突）、1146（表不存在）、1032（行不存在）——这些数字比错误描述更可靠
如果 Last_SQL_Error 里出现 GTID 相关字样（如 Attempted to execute replication event with GTID that was already executed），说明是 GTID 模式下事务重复或错位，不能用老办法跳过。
确认是否启用 GTID，再决定怎么查错误事务
执行 SHOW VARIABLES LIKE 'gtid_mode';，结果是 ON 就必须走 GTID 路径，OFF 才能考虑 sql_slave_skip_counter。5.7.3+ 默认开启，生产环境基本都是 ON。
- GTID 模式下，
Retrieved_Gtid_Set是从库已拉到的 GTID 集合，Executed_Gtid_Set是已执行的集合；两者差集就是“卡住但没执行”的事务 - 用
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;可看到当前 Coordinator 卡在哪个 GTID 上（LAST_PROCESSED_TRANSACTION字段） - 不要依赖
Relay_Master_Log_File+Exec_Master_Log_Pos去主库查 binlog——GTID 模式下这个位置可能已失效，且主库 binlog 可能被 purge
用 mysqlbinlog 定位出错事务的真实 GTID
仅靠 SHOW SLAVE STATUS 给出的 GTID 不一定准确，尤其当 relay log 损坏或未刷盘时。稳妥做法是结合 binlog 文件反查：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 从
SHOW SLAVE STATUS\G中拿到Relay_Master_Log_File（比如mysql-bin.000023）和Exec_Master_Log_Pos（比如1984） - 去主库（或从库已保留的 binlog 目录）执行：
mysqlbinlog --base64-output=decode-rows -v /var/lib/mysql/mysql-bin.000023 | grep -A 3 -B 3 "SET @@SESSION.GTID_NEXT" | grep -E "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}:[0-9]+" | head -n 5 - 往前/往后多看几条，找到紧邻
Exec_Master_Log_Pos位置的那个完整 GTID（格式如3e11fa47-71ca-11e1-9e33-c80aa9429562:23），它大概率就是让 SQL 线程停住的那条
注意：如果主库该 binlog 已被 PURGE BINARY LOGS 删除，就无法通过此方式定位——此时只能重建从库，别硬试跳过。
跳过前必须人工验证那条事务是否可丢
跳过不是恢复，是绕开。每跳一次，都意味着你主动放弃了一次数据一致性校验机会。
- 对
1062错误：先在从库执行SELECT * FROM tbl WHERE id = XXX;，确认这条记录是业务误写进从库，还是主库本不该发这条——前者可删从库脏数据，后者才考虑跳过 - 对
1146错误：查主库是否存在该表、是否在replicate-ignore-db或binlog-ignore-db列表里，避免补建表后又因忽略规则导致后续同步失败 - 跳过操作本身要原子：必须
STOP SLAVE→SET GTID_NEXT='xxx'→BEGIN; COMMIT;→SET GTID_NEXT='AUTOMATIC'→START SLAVE，中间任何一步中断都会让 GTID 状态异常
最常被忽略的一点：跳过之后，Seconds_Behind_Master 变成 0 并不等于数据一致。务必用 pt-table-checksum 对核心表做校验，否则下次故障切换可能直接炸库。
