MySQL恢复时如何跳过特定错误代码继续执行

首先给出核心结论：在MySQL命令行还原场景下，--force 参数是最为直接且有效的错误跳过方式。它能够忽略重复键、唯一键冲突等约束性错误，使脚本继续执行后续命令。不过需要注意的是，它并不能跳过严重语法错误，例如列不存在等错误，该中断时仍会中断。此外，它无法修复逻辑上的语义断裂问题。至于网络上流传的 SET sql_mode='IGNORE' 之类的做法，实际上不可行，因为MySQL并未定义该模式值。slave_skip_errors 仅适用于复制场景，本地还原无法生效。INSERT IGNORE 仅对单条INSERT语句有效，对批量执行整个SQL文件并无帮助。

MySQL命令行还原时使用 --force 跳过错误

在命令行直接使用 mysql < file.sql 执行还原操作时，加上 --force 是最常用且最有效的方法之一。它使客户端在遇到大多数错误（如重复主键、唯一键冲突、语法警告等）时忽略这些错误，并继续读取与执行后续语句。但有几个细节需要注意：

• --force 不会忽略严重语法错误，例如 Unknown column 'xxx' in 'field list' 这类错误仍会导致执行终止。但对于约束类错误，如 Duplicate entry 或 Cannot add or update a child row，则通常可以跳过。
• 被跳过的错误信息仍会输出到标准错误流（stderr）。建议在命令中添加重定向记录，例如：mysql -u root -p --force mydb < restore.sql 2> restore_errors.log，这样方便事后检查。
• 特别说明：--force 属于客户端参数，不影响服务端配置，也不涉及复制状态。还原完成后，务必仔细检查 restore_errors.log，确认跳过了哪些错误，避免遗漏本应处理的错误。

还原前使用 SET sql_mode = 'IGNORE' 是否有效？

答案是否定的，无效。SET sql_mode='IGNORE' 该语句根本不合法——MySQL 的 sql_mode 中并未定义 IGNORE 值。网络上一些教程混淆了 INSERT IGNORE 与全局模式，这是常见误区，切勿轻信。

• 实际可设置的宽松模式，例如 NO_ENGINE_SUBSTITUTION 或者去掉 STRICT_TRANS_TABLES，但这些并不能使整个还原过程“跳过错误继续执行”。它们仅放宽某些严格限制，遇到错误仍会中止。
• 若希望单条 INSERT 具备容错能力，则必须显式使用 INSERT IGNORE 或 INSERT ... ON DUPLICATE KEY UPDATE。
• 在批量还原场景下，依赖修改 sql_mode 实现跳过完全不可靠，建议放弃此思路。

slave_skip_errors 仅适用于复制场景，不适用于还原

slave_skip_errors 是从库（slave）的专用配置，仅影响 SQL 线程回放 relay log 时的行为，与本地执行 mysql < file.sql 完全不同。

• 例如，若设置 slave_skip_errors = 1062,1032，从库遇到重复键（1062）或找不到行（1032）时，将跳过对应的事件。但在主库执行还原时，该参数完全无效。
• 更危险的是，若在主库误设此参数，不仅无效，还可能掩盖复制异常，导致主从数据逐渐偏离。
• 若还原的是从库备份且需要临时跳过复制错误，正确做法是：先执行 STOP SLAVE，再使用 SET GLOBAL sql_slave_skip_counter = 1（传统复制）或通过 GTID 注入（GTID 复制），而非修改 slave_skip_errors。

INSERT IGNORE 与 ON DUPLICATE KEY UPDATE 的适用边界

这两个关键字仅对单条 INSERT 语句有效，不能期望它们让整个 SQL 文件“跳过错误继续执行”。它们是编写导入逻辑时主动采用的防御性设计，而非还原工具层面的开关。

• INSERT IGNORE 在遇到重复键、NOT NULL 冲突等时返回警告而非错误，语句本身视为成功。适用于批量插入中容忍少量脏数据。
• ON DUPLICATE KEY UPDATE 更为可控：冲突时执行更新，可避免丢失业务语义，例如计数器累加等场景。
• 但需注意，若 SQL 文件中包含 CREATE TABLE、ALTER TABLE、UPDATE 等其他语句，这些关键字完全无效——它们仅修饰 INSERT，对其他语句不适用。

实际还原过程中，最易被忽略的一点是：--force 能跳过的错误类型有限，且无法修复语义断裂。例如，一条 INSERT 因外键约束失败被跳过，但后续依赖该记录的 UPDATE 或 DELETE 语句仍会失败，最终可能导致整块关联数据被静默丢弃。因此，要确保数据完整性，在还原前进行预清洗，远比盲目跳过错误更为可靠。