根本原因是Navicat数据传输默认硬写源表AUTO_INCREMENT值到目标表CREATE语句末尾，导致新插入记录主键冲突；需在传输向导高级选项中取消“Include AUTO_INCREMENT value”，并用ALTER TABLE SET AUTO_INCREMENT = COALESCE(MAX(id), 0) + 1修复。
Navicat数据传输时AUTO_INCREMENT被硬覆盖的真相
根本不是“传输失败”，而是Navicat在数据传输（Data Transfer）过程中，默认把源表的AUTO_INCREMENT=12345原样写进目标表的CREATE TABLE语句末尾——哪怕目标表当前最大id是99999，它也会强行设成12345，下一条插入就撞上重复主键。
这个行为藏在「高级」选项里，且每次新建传输任务都默认开启、不记忆上次设置。你看到的Duplicate entry '12345' for key 'PRIMARY'错误，其实只是结果，不是原因。
- 检查导出的SQL文件：用文本编辑器打开，搜索
AUTO_INCREMENT=，看数值是否远小于目标表现有最大ID - 传输向导中关闭该选项：点击「高级」→ 找到
Include AUTO_INCREMENT value→ 取消勾选 - 若已启用「Generate SQL only」预览模式，务必确认生成的SQL里不再出现
AUTO_INCREMENT=等号赋值
数据传输后自增起点错乱的即时修复
别删表重建。只要目标表没被长事务锁住，一条ALTER TABLE就能对齐，但必须用动态计算值，不能写死1或随便填。
- 先查安全起点：
SELECT COALESCE(MAX(id), 0) + 1 FROM your_table; - 再执行重置：
ALTER TABLE your_table AUTO_INCREMENT = 100001;（把100001替换成上一步结果） - 注意：如果子查询返回
NULL（比如表为空），COALESCE能兜底；不加它直接用MAX(id) + 1会报错 - 执行前用
SHOW CREATE TABLE your_table;确认当前AUTO_INCREMENT值，避免重复操作
为什么Navicat「设计表 → Auto Increment」填1完全无效
那个输入框不是重置开关，它底层执行的是ALTER TABLE your_table AUTO_INCREMENT = 1——而MySQL只接受大于当前最大id的值。填1在绝大多数情况下等于白点。
- 表里已有
id = 500的记录？填1 → 被MySQL静默忽略，SHOW CREATE TABLE里仍是AUTO_INCREMENT=501 - 表为空？填1 → 有可能生效，但InnoDB引擎下重启或表重建后可能丢失
- 想彻底归零？先
TRUNCATE TABLE your_table;（确保真为空），再填1并保存，才可能成功 - 更稳妥的做法：跳过界面，直接用
ALTER TABLE命令设为MAX(id)+1，一劳永逸
跨平台/跨环境传输时最容易被忽略的陷阱
本地macOS开发库同步到Linux测试库，冲突率极高——不是因为平台差异，而是目标库常为空或只有几条测试数据，而源库AUTO_INCREMENT=89234被无脑同步过去，新插入第一条就从89234开始，跳过所有小ID。
- 同步前必查目标状态：
SELECT IFNULL(MAX(id), 0) FROM your_table; - 同步后必补重置语句，不能依赖Navicat自动处理
- 若用PostgreSQL，对应逻辑是：
SELECT setval('your_table_id_seq', (SELECT MAX(id) FROM your_table)); - MySQL 8.0+用户额外注意：
innodb_autoinc_lock_mode = 2（默认）会导致批量插入ID序列在不同环境不一致，这不是Navicat问题，但会放大错乱感知
实际修复动作往往就两步：关掉Include AUTO_INCREMENT value，再跑一句带COALESCE(MAX(id), 0) + 1的ALTER TABLE。但多数人卡在第一步没找到开关，或第二步写了ALTER TABLE ... AUTO_INCREMENT = 1却以为已经修好。
