<p>ERROR 1062故障须先区分“目标库非空”或“备份含重复”：执行SELECT * FROM table_name WHERE id = 123确认；目标库非空则需清空，为空则检查备份触发器、--replace误用或缺失SET UNIQUE_CHECKS=0；禁用手动改SQL，优先用--force或--init-command控制恢复；GTID模式下必须用SET GTID_NEXT跳过，不可用sql_slave_skip_counter。</p>
遇到 ERROR 1062 (23000): Duplicate entry，别急着加 INSERT IGNORE 或删表重来——先确认这重复到底是“目标库脏了”，还是“备份本身就有病”。90% 的修复失败，源于没分清这两类源头。
查清楚是目标库已有数据，还是备份文件自带重复
报错里带具体值，比如 Duplicate entry '123' for key 'PRIMARY'，立刻执行：
-
SELECT * FROM table_name WHERE id = 123;—— 如果返回记录，说明你正在往一个非空库上恢复，根本问题不是数据错，而是没清库 - 如果目标库确实为空（
SELECT COUNT(*) FROM table_name;返回 0），但还报这个错，那问题在备份：可能是导出时用了--replace但源库主键已乱；也可能是触发器在导入时二次插入；还可能是备份 SQL 文件头缺SET UNIQUE_CHECKS=0;，导致约束提前校验
用 mysql 客户端参数控制恢复，别改 SQL 文件
几百 MB 的 SQL 文件，手动加 IGNORE 或删 CREATE TABLE 极易出错。直接用命令行开关更稳：
- 加
--force：遇到单条错误（包括1062）跳过并继续，但不会输出跳过了哪几行，适合快速恢复+事后核对 - 加
--init-command="SET SESSION sql_mode='STRICT_TRANS_TABLES';"：提前暴露日期非法、字段超长等隐藏问题，避免1062掩盖真正病因 - 对含大量
INSERT INTO ... SELECT的备份，建议拆成小批次导入，例如用split -l 1000分割后逐个运行，方便定位错误行号
GTID 模式下从库恢复，sql_slave_skip_counter 失效
如果你的从库启用了 GTID（SHOW VARIABLES LIKE 'gtid_mode'; 返回 ON），SET GLOBAL sql_slave_skip_counter = 1; 会直接报错 ERROR 1251 或 ERROR 1858，完全不能用：
- 必须从
SHOW SLAVE STATUS\G的Last_SQL_Error字段里精确提取 GTID，格式如3e11fa47-71ca-11e1-9e33-c80aa9429562:23（冒号前后无空格、大小写严格一致） - 按顺序执行：
STOP REPLICA;→SET GTID_NEXT = 'xxx:yyy';→BEGIN; COMMIT;→SET GTID_NEXT = 'AUTOMATIC';→START REPLICA;
最常被忽略的一点：报错里的 key 'PRIMARY' 并不总指主键列——它可能对应第一个唯一索引（key 1）。用 SHOW INDEX FROM table_name; 确认实际冲突字段，否则查错方向全偏。
