alter table ... auto_increment=n 仅在 n 大于当前最大主键值时生效；否则 mysql 静默忽略，innodb 尤其严格；truncate 才能真正重置计数器，但受外键和权限限制。
ALTER TABLE ... AUTO_INCREMENT= 为什么有时不生效
直接执行 ALTER TABLE t1 AUTO_INCREMENT = 100; 后插入新记录，ID 仍从旧最大值+1开始？常见于表里已有数据但没触发自增更新逻辑。MySQL 只在 AUTO_INCREMENT 值小于当前最大主键值时，才会自动上调到 MAX(id) + 1；如果设的值比现有最大 ID 小，它就默默忽略。
- 必须确保目标值大于当前
MAX(id)，否则无效（可先查：SELECT MAX(id) FROM t1;） - 对空表设
AUTO_INCREMENT=1有效；但非空表设为 1，实际插入仍从 2 开始（除非用TRUNCATE） - MyISAM 表支持设任意值（只要不冲突），InnoDB 更严格，会校验并可能静默修正
TRUNCATE 比 DELETE + ALTER 更彻底
想清空表并重置自增 ID，别用 DELETE FROM t1; 再 ALTER——DELETE 不重置计数器，TRUNCATE 才是真正“归零”操作。
-
TRUNCATE t1;会重置AUTO_INCREMENT到初始值（通常是 1），且不可回滚、不走逐行删除逻辑 - 但
TRUNCATE会失败：如果表被外键引用（报错Cannot truncate a table referenced in a foreign key constraint），需先删外键或改用DELETE+ALTER组合 - 注意权限：
TRUNCATE需要DROP权限，而DELETE只需DELETE权限
迁移后 ID 不连续的根本原因不是“坏了”
从旧库导出再导入（比如用 mysqldump --no-autocommit 或 INSERT ... SELECT），ID 不连续是正常现象，不是配置错误或损坏。
- 源库中跳过的 ID（如事务回滚、
REPLACE、INSERT IGNORE失败）不会被导出，目标库按导入顺序生成新 ID，自然不继承“空洞” - 若用
mysqldump --skip-extended-insert，每条INSERT单独提交，自增行为更贴近源库；但默认的批量插入会一次性申请多个 ID，加剧不连续 - ID 不连续不影响查询、索引、性能，唯一影响是业务上“看着不整齐”，别为此强行重排主键
RESET AUTO_INCREMENT 的安全边界在哪里
线上表慎用重置操作，尤其当有应用缓存了旧 ID、或下游依赖 ID 顺序做分页/幂等判断时。
- 重置前确认无写入：至少加个
READ LOCK或停写，否则可能和并发插入冲突，导致重复 ID 或主键冲突 - 不要在从库执行
ALTER TABLE ... AUTO_INCREMENT，GTID 或 binlog 复制可能让主从自增值不一致，引发同步中断 - 如果只是想“让下一条从 N 开始”，且 N >
MAX(id)，用ALTER TABLE ... AUTO_INCREMENT = N;最轻量；别为了省事去重建表
