根本原因是AUTO_INCREMENT计数器未随数据同步更新；MySQL只认自身存储的计数器值，而非MAX(id)，故恢复后需通过SHOW TABLE STATUS对比并手动重置，TRUNCATE是唯一可靠归零方式。
恢复后自增主键冲突，根本原因不是数据错了，而是 AUTO_INCREMENT 计数器没跟着数据同步更新——MySQL 不会自动把计数器设成 MAX(id) + 1，它只认自己内存/磁盘里存的那个值。
查清真实 Auto_increment 值比猜更管用
很多人一上来就 ALTER TABLE t AUTO_INCREMENT = 1，结果无效，是因为没先看当前表状态。MySQL 的插入行为只取决于 SHOW CREATE TABLE t 输出里的 AUTO_INCREMENT=xxx，而不是 SELECT MAX(id)。
-
SELECT MAX(id) FROM t返回 999，不代表下一条就是 1000；如果SHOW CREATE TABLE t显示AUTO_INCREMENT=500，那下一条就是 500（撞上已存在 id 就报ERROR 1062） - 必须同时执行两个命令确认：
SELECT COALESCE(MAX(id), 0) FROM t和SHOW TABLE STATUS LIKE 't'，对比前者和后者字段Auto_increment的大小 - 若
MAX(id) >= Auto_increment，就必须重置：执行ALTER TABLE t AUTO_INCREMENT = COALESCE(MAX(id), 0) + 1
TRUNCATE 是唯一能真正归零的可靠操作
TRUNCATE TABLE t 是唯一能让 AUTO_INCREMENT 回到 1 的方式，但它要求表为空且无外键引用。恢复后想从 1 开始，不能靠 ALTER 补救，只能靠它。
-
TRUNCATE会清空数据 + 重置计数器 + 释放空间，三件事一步到位 - 有外键时直接报错：
Cannot truncate a table referenced in a foreign key constraint；此时需临时关检查：SET FOREIGN_KEY_CHECKS = 0，再TRUNCATE，完后立刻SET FOREIGN_KEY_CHECKS = 1 - 别用
DELETE FROM t替代 —— 它不重置计数器，ALTER TABLE t AUTO_INCREMENT = 1在非空表中必然静默失效
主从或跨实例恢复时偏移风险更高
主库导出再导入从库，或用 Xtrabackup 恢复，极易出现主从 Auto_increment 不一致。这不是“乱”，是 MySQL 8.0+ 自增持久化机制导致的：重启或恢复后，InnoDB 会扫描全表找最大 id 来初始化计数器，但这个扫描可能不触发、不完整，或被缓存干扰。
- 恢复后务必在主从分别执行
SHOW TABLE STATUS LIKE 't'，比对Auto_increment字段差值 - 不要在从库直接
ALTER TABLE t AUTO_INCREMENT = N—— 这会破坏主从同步逻辑；应改全局变量：SET GLOBAL auto_increment_offset = N，配合auto_increment_increment错开生成范围 - GTID 模式下冲突概率低，但多源复制或合并库场景仍需人工校准，不能依赖自动修复
最常被忽略的一点：AUTO_INCREMENT 是表级元数据，不是行数据，它不会随 mysqldump 中的 INSERT 语句一起恢复。备份文件里没有它，还原时 MySQL 就按自己规则初始化——而这个规则，在 8.0.20+ 版本中变得更隐蔽也更依赖启动时的扫描行为。
