slave_skip_errors不能随便开启，仅作临时兜底，跳过会导致主从数据不一致；MySQL 8.0.26+已废弃，推荐用sql_slave_skip_counter或GTID方式单条跳过。
mysql从库报1032或1062错误时，slave_skip_errors真能用？
不能随便开。这个配置是“跳过复制错误”的开关，但只对特定错误类型生效，且跳过之后主从数据必然不一致——它不是修复手段，而是临时兜底方案。
常见错误现象：Seconds_Behind_Master卡住、SHOW SLAVE STATUS\G里出现 Slave_SQL_Running: No，Last_SQL_Errno 显示 1032（行不存在）、1062（唯一键冲突）等。
-
slave_skip_errors只影响 SQL 线程（即回放 relay log 的线程），不影响 IO 线程 - 必须在从库
my.cnf中配置并重启 mysqld 才生效，动态 SET 不支持 - MySQL 8.0.26+ 已废弃该参数，推荐改用
SET GLOBAL sql_slave_skip_counter = 1或 GTID 模式下的gtid_next跳过（但仅限单条） - 值可以是具体错误号（如
1032,1062），也可以是all（极度危险，不建议）
如何安全地跳过一个 1062 错误（唯一键冲突）
核心原则：先确认冲突是否可接受，再决定跳过。比如从库多删了一条记录，导致主库重插时报 1062，这种场景才考虑跳过。
操作前务必执行：STOP SLAVE;，然后检查当前执行到哪条事件：SHOW SLAVE STATUS\G，重点关注 Relay_Log_File 和 Exec_Master_Log_Pos。
- 如果用的是传统 binlog 位置复制：运行
SET GLOBAL sql_slave_skip_counter = 1;，再START SLAVE; - 如果用的是 GTID 复制：先
SET @@SESSION.GTID_NEXT = 'xxx-xxx-xxx:nnn';（填Retrieved_Gtid_Set中下一条未执行的 GTID），再BEGIN; COMMIT;，最后START SLAVE; - 跳过后立刻验证：
SELECT * FROM table_name WHERE ...确认那条冲突数据是否已存在，避免后续语句因状态错乱再出错
slave_skip_errors 在配置文件里怎么写才不踩坑
写进 my.cnf 的 [mysqld] 段后，MySQL 启动时会加载。但注意几个硬性限制：
- 值之间用英文逗号分隔，**不能有空格**：
slave_skip_errors=1032,1062✅，slave_skip_errors=1032, 1062❌（会解析失败） - MySQL 5.7 支持错误号或符号名（如
duplicate-key），但建议统一用数字，避免版本差异 - 配置后必须重启 mysqld，
FLUSH PRIVILEGES或RELOAD无效 - 跳过的错误不会记入 error log，默认静默处理，排查时容易遗漏——建议同时开启
log_warnings = 2
为什么跳过错误后，Seconds_Behind_Master 还是增长？
因为 slave_skip_errors 只让 SQL 线程跳过报错事件，继续执行下一条；但如果 relay log 里连续多条都依赖前一条状态（比如 INSERT 后跟 UPDATE），跳过中间一条会导致后续语句持续失败，SQL 线程反复停住。
- 典型表现：
Last_SQL_Errno变了，但Slave_SQL_Running仍为No - 此时不是配置没生效，而是问题没根治——得查主库那段时间的业务逻辑，是否做了不幂等操作
- 更稳妥的做法是：导出从库对应表的数据，用 pt-table-checksum + pt-table-sync 校验修复，而不是靠跳过硬扛
- 长期靠
slave_skip_errors维持同步，等于默认放弃数据一致性，DBA 很快会收不到告警，直到某天发现订单对不上
真正难的从来不是怎么跳过错误，而是怎么判断“这条错误能不能跳”——它需要你清楚知道那条 SQL 在主库上干了什么、在从库上为什么失败、跳过之后其他关联数据会不会断链。这些信息，SHOW SLAVE STATUS 不会告诉你，得翻 binlog 或业务日志。
