Navicat定时任务导致MySQL AUTO_INCREMENT异常跳号，主因是预分配机制、TRUNCATE重置、结构同步覆盖及显式插入ID未调计数器。
Navicat定时任务执行INSERT时触发MySQL预分配机制
mysql对批量insert（包括navicat生成的多行insert或insert ... select）采用幂次预分配id策略：哪怕只插5行，也可能预先申请1→2→4→8个id槽位。定时任务若每次导入n条数据，实际消耗的id数远大于n，且这部分“预留但未用”的id永久丢失。这不是navicat的bug，是innodb为并发性能做的底层设计，innodb_autoinc_lock_mode设为2（mysql 8.0+默认）时更明显。
定时任务重复运行导致AUTO_INCREMENT被反复重置
常见于两种情况：TRUNCATE TABLE后重建自增起点，或结构同步时未关AUTO_INCREMENT。Navicat定时任务若配置了“清空目标表再导入”，每次都会重置AUTO_INCREMENT = 1；而如果目标表已有数据，下次插入就会撞上已存在的ID，触发错误或跳号。更隐蔽的是：结构同步任务若在「高级」里没取消勾选AUTO_INCREMENT，会把源库当前值（比如AUTO_INCREMENT = 892）硬写进目标表DDL，完全无视目标表真实最大ID。
导入时显式写入ID列但没调正计数器
- 源Excel/CSV含ID列，Navicat导入向导中勾选了该列映射 → 所有ID被显式插入，但
AUTO_INCREMENT计数器仍停留在旧值 - 定时任务跑完后，新插入记录从旧计数器值开始，而非
MAX(id) + 1，造成断层 - 正确做法：导入完成后立即执行
ALTER TABLE table_name AUTO_INCREMENT = (SELECT IFNULL(MAX(id), 0) + 1 FROM table_name) - 别用
ALTER TABLE ... AUTO_INCREMENT = 1，除非确认表为空——否则必报Duplicate entry 'X' for key 'PRIMARY'
事务回滚或失败导入残留ID消耗
定时任务中途失败（如网络中断、权限不足、外键冲突），已分配的部分ID不会回收。例如任务尝试插入100行，第37行失败并回滚，前36个ID已被占用，下次成功运行时从37开始分配——但MySQL计数器已跳到100+，实际新ID从101起。这类跳变无法预测，只能接受。真正要防的是人为误操作：比如手动DELETE后忘记重置计数器，或用INSERT IGNORE导入重复主键时，计数器仍会前进。
AUTO_INCREMENT开关——它不报错、不提示，只安静地把你生产库的自增起点覆盖成测试库的值。 
