ALTER TABLE AUTO_INCREMENT=N不生效，是因为MySQL要求N必须大于当前表最大主键值，否则静默忽略；空表可设任意正整数，非空表则取MAX(id)+1与N的较大者；TRUNCATE是唯一可靠重置方式，会话变量@auto_increment_offset对单表无效。
ALTER TABLE AUTO_INCREMENT=N 为什么总不生效？
因为 MySQL 的 AUTO_INCREMENT 值不会低于当前表中已存在的最大主键值。哪怕你执行 ALTER TABLE t AUTO_INCREMENT = 100，只要表里已有 id = 150 的记录，下次插入仍从 151 开始——MySQL 静默忽略该语句，不报错也不警告。
验证当前最大值用：SELECT MAX(id) FROM t；确认当前 AUTO_INCREMENT 实际值用：SHOW CREATE TABLE t（看建表语句末尾的 AUTO_INCREMENT=xxx）。
- 空表可设任意正整数，比如
ALTER TABLE t AUTO_INCREMENT = 1立即生效 - 非空表时，MySQL 内部取
MAX(id) + 1和你指定值的较大者，不是直接覆盖 - 想设成小于等于当前最大 ID 的值，等同于没写这句
想“重置”到小数值，但又不能删数据怎么办？
物理上无法绕过最大 ID 约束。如果你的表有数据，且希望下一条插入从 1 开始，唯一可靠路径是清空数据：
-
TRUNCATE TABLE t：会重置计数器为 1，速度快，但不可回滚，且外键存在时会失败 -
DELETE FROM t+ALTER TABLE t AUTO_INCREMENT = 1：保留结构和索引，但必须确保DELETE后表真为空（检查SELECT COUNT(*)），否则ALTER仍被忽略
注意：DELETE 本身不重置 AUTO_INCREMENT，必须显式跟 ALTER；而 TRUNCATE 是原子操作，自动完成重置。
@auto_increment_offset 对单表完全无效
会话变量 @auto_increment_offset 和 @auto_increment_increment 只在特定场景起作用：主从复制、双主架构或分库分表中协调 ID 分布。它们对普通单表的 ALTER TABLE ... AUTO_INCREMENT= 没有任何影响。
- 设置
SET @auto_increment_offset = 5后执行INSERT INTO t VALUES ()，ID 仍按原计数器走，不会跳到 5 - 该变量只参与 INSERT 时的“动态计算”，不修改表级元数据中的
AUTO_INCREMENT值 - 重启连接后，这些会话变量恢复全局默认值（
SHOW VARIABLES LIKE 'auto_increment_%'可查）
InnoDB 大表修改 AUTO_INCREMENT 的实际代价
在 InnoDB 表上执行 ALTER TABLE ... AUTO_INCREMENT=N，即使 N 大于当前最大值，MySQL 8.0+ 也仍会触发 ALGORITHM=COPY（全表拷贝），而非真正的在线 DDL。这意味着：
- 锁表时间与表大小正相关，千万级以上行数需评估维护窗口
- 磁盘空间需额外预留一倍（临时表生成期间）
- MySQL 5.7 在某些含 NULL 的唯一索引场景下可能静默失败（不报错但未更新）
真正容易被忽略的是：InnoDB 在服务器重启后会扫描全表找最大 ID 并加 1，而不是读内存缓存——所以你以为设好了，重启后可能发现它“自己跳高了”。
