根本原因是还原时主键自增值与表中已有数据错位：mysqldump不重置auto_increment，若目标表非空或曾部分导入，显式插入id与当前自增值冲突，导致后续自增insert撞上已存在主键。
MySQL 5.7 逻辑还原时出现 Duplicate entry 错误，根本原因不是数据本身重复，而是还原过程中主键自增值与表中已有数据错位，导致 INSERT 语句试图写入已存在的主键值。
还原时 Duplicate entry 'X' for key 'PRIMARY' 的真实来源
mysqldump 生成的 SQL 文件默认包含 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO'; 等上下文，但关键点在于：它不会显式重置表的 AUTO_INCREMENT 值。如果目标库中该表已有数据（比如从旧备份残留、或之前部分导入过），而 dump 文件里第一条 INSERT 的主键值（如 1）恰好小于当前表的 AUTO_INCREMENT 值，后续靠自增插入的语句就可能撞上已存在的记录。
更隐蔽的情况是：dump 文件中混有 INSERT INTO ... VALUES (1,...), (2,...) 显式指定主键 + 后续无主键的 INSERT INTO ... VALUES (...)（依赖自增）。一旦中间某条显式插入的 ID 恰好等于当前自增值，下一条自增插入就会冲突。
- 错误信息里的
'47071930'往往是表里“确实存在”的主键，但你查不到，是因为还原中途被部分执行卡住，状态不一致 - 不是 mysqldump 导出的数据有重复，而是导入时执行顺序和自增状态没对齐
- 即使源库没冲突，目标库若非空或曾执行过 DDL，
AUTO_INCREMENT就可能漂移
mysqldump 还原前必须检查的三项状态
在执行 mysql -u... 前，先连上目标库，对每个将被还原的表运行：
SHOW TABLE STATUS LIKE 'table_name';
重点关注三列：
-
Auto_increment：下一条自增插入会用的值 -
Rows：InnoDB 估算行数（不一定准，但可作参考） -
Data_length：确认表是否为空（为 0 通常表示空表）
再查最大主键值：
SELECT MAX(id) FROM table_name;
如果 MAX(id) ≥ Auto_increment，说明自增值已滞后，必须修正；如果表非空但 Auto_increment 是 1，基本必报错。
安全还原的实操步骤（避免主键冲突）
不要直接管道导入。按以下顺序操作：
- 先清空目标表：
TRUNCATE TABLE table_name;（注意：这会重置AUTO_INCREMENT为 1，且不可回滚） - 或保留数据但重置自增：
ALTER TABLE table_name AUTO_INCREMENT = <safe_start_value>;</safe_start_value>，其中<safe_start_value></safe_start_value>至少设为MAX(id) + 1 - 确保 dump 文件不含
CREATE TABLE语句（用mysqldump --no-create-info重导），或手动删掉，防止重建表时覆盖原有AUTO_INCREMENT - 导入时加
--init-command="SET FOREIGN_KEY_CHECKS=0;"避免外键干扰，但记得之后补回
如果你必须保留历史数据并追加导入，就别用 INSERT，改用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE —— 但这要求你提前修改 dump 文件，把所有 INSERT INTO 替换为带冲突处理的语法，成本高且易出错。
为什么 INSERT IGNORE 不是万能解药
它只是掩盖问题，不是修复根源：
- 主键冲突时静默跳过，但业务上你可能需要知道哪条丢了
- 如果表有唯一索引（不止主键），
IGNORE也会跳过那些冲突，容易漏数据 - dump 文件中如果有
REPLACE INTO，它实际是「删+插」，在大表上会锁表、产生大量 binlog、触发从库延迟 - 最麻烦的是：某些 ORM 或迁移工具生成的 dump 会混合
INSERT和REPLACE，你无法靠统一替换解决
真正要稳，就得控制源头：还原前清空或对齐自增状态，而不是依赖 SQL 层的容错机制。这个细节在跨环境迁移、多版本共存（如 5.7 → 8.0）时尤其容易被忽略——因为 8.0 默认排序规则变更会进一步干扰字符字段的隐式比较，让主键冲突看起来像乱码问题。
