表结构变更失败时不能跳过，因“Table 'db.t1' doesn't exist”等错误表明schema不一致，跳过将导致后续依赖持续报错；应停SQL线程、从库补对象或比对SHOW CREATE TABLE。
遇到表结构变更失败时不能跳过
主从复制中若 Last_SQL_Error 显示类似 “Table 'db.t1' doesn't exist” 或 “Unknown column 'x' in 'field list'”，基本说明从库缺失建表语句、字段或索引。这类错误本质是 schema 不一致，跳过只会让后续所有依赖该表/字段的操作持续报错。
常见诱因包括：
- 主库执行了
CREATE TABLE或ALTER TABLE，但该语句未成功写入 binlog（如事务被回滚、binlog_format=STATEMENT 下含非确定性函数） - 从库曾手动删表或改结构，且未同步到主库
- 主从
sql_mode不一致导致 DDL 解析失败
此时应停掉 SQL 线程，先在从库补上缺失对象，再 START SLAVE；若不确定变更内容，直接比对主从 SHOW CREATE TABLE 输出。
relay log 损坏或位置错乱时禁止跳过
当 SHOW SLAVE STATUS\G 中 Relay_Log_File 和 Relay_Log_Pos 明显异常（如文件名不连续、pos 跳变极大），或错误日志出现 “Corrupted replication event”、“Invalid event in relay log” 等字样，说明 relay log 本身已损坏。
此时 sql_slave_skip_counter 或 SET GTID_NEXT 都无效——因为跳过动作依赖 relay log 的事件边界，而边界已不可信。强行跳过可能导致后续事件解析错位，SQL 线程反复崩溃。
可靠做法是：
- 确认主库当前
SHOW MASTER STATUS的File和Position - 在从库执行
STOP SLAVE; RESET SLAVE ALL;清空 relay log 和复制元数据 - 用
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy重新指向主库最新合法位置 - 再
START SLAVE
并行复制下无主键表报 1032 错误时慎跳
MySQL 8.0+ 开启并行复制（slave_parallel_workers > 0）且表无主键时，Last_SQL_Error: Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND 很可能不是真丢失数据，而是 HASH_SCAN 算法哈希冲突导致的误判。
这种场景跳过会掩盖真实问题：
- 跳过之后，同一事务可能在其他 worker 中重放成功，造成主从数据“部分同步”
- 下次更新仍可能因哈希冲突再次报 1032，形成循环
- 根本解法是给表加主键，或临时关闭并行复制：
SET GLOBAL slave_parallel_workers = 0
若必须跳过，务必先查 SELECT COUNT(*) FROM db.table 主从是否一致，并确认该表近期无手工 DELETE/UPDATE 操作。
启用 slave_skip_errors 全局配置后仍报错时不要硬跳
如果已在配置文件中设置了 slave_skip_errors = 1062,1032，但 SHOW SLAVE STATUS 仍显示 Slave_SQL_Running: No，说明错误码不在白名单内，或错误类型不匹配（比如报的是 1236、1410 等严重错误）。
典型陷阱：
-
slave_skip_errors = ALL在 MySQL 8.0.26+ 已被弃用，设了也无效 - GTID 模式下该参数完全不生效，跳过逻辑由 GTID 集合控制
- 某些错误（如 1236 “Could not find first log file name in binary log index file”）属于 IO 层故障，和 SQL 执行无关，跳过毫无意义
此时应优先检查主库 binlog 是否被 purge、网络是否中断、或磁盘空间是否满，而不是尝试绕过错误码。
真正危险的不是跳过那条语句，而是跳过之后没发现 auto-increment 值偏移、唯一索引残留脏数据、或 binlog_format=STATEMENT 下 NOW() 导致的时间戳错位——这些不会立刻报错，但会在下一次 INSERT 或 UPDATE 时突然爆发，且难以回溯。
