ALTER TABLE table_name AUTO_INCREMENT = 100仅在100 > MAX(id)时生效，否则静默忽略；需先查SELECT MAX(id)，再用SHOW CREATE TABLE确认当前AUTO_INCREMENT值；非空表重置为1须先TRUNCATE或DELETE后ALTER。
ALTER TABLE 之后 AUTO_INCREMENT 没生效？检查当前最大值
直接执行 ALTER TABLE table_name AUTO_INCREMENT = 100; 不一定生效，MySQL 会自动校验：新值必须大于表中现有所有 id 的最大值。如果当前最大 id 是 95，设成 100 没问题；但如果设成 90，语句会静默失败（无报错，但实际值不变）。
- 先查当前最大值：
SELECT MAX(id) FROM table_name; - 再确认当前 AUTO_INCREMENT 值：
SHOW CREATE TABLE table_name;（看输出里AUTO_INCREMENT=xxx那行） - 若要重置为 1，且表非空，得先清空数据或用
TRUNCATE TABLE（它会重置计数器，但会删数据、重置外键约束）
TRUNCATE 和 DELETE 对 AUTO_INCREMENT 的影响完全不同
DELETE FROM table_name; 只删数据，AUTO_INCREMENT 计数器保持不变；TRUNCATE TABLE table_name; 则会重置计数器（在 InnoDB 中，从 1 开始，除非显式指定），但它有副作用：不能回滚、会重置自增计数器、会重置 AUTO_INCREMENT 值、还会释放空间。
- 想清空数据并重置 ID：用
TRUNCATE TABLE（注意：它会绕过触发器、不记录逐行日志） - 只想删部分数据且保留后续 ID 连续性：用
DELETE，然后手动ALTER TABLE ... AUTO_INCREMENT = N;（N 必须 > 当前 MAX(id)） - MyISAM 表下
TRUNCATE等价于DROP + CREATE，InnoDB 下是优化过的快速清空，但行为一致：重置 AUTO_INCREMENT
修改后插入新记录仍从旧值开始？可能被 INSERT IGNORE 或 ON DUPLICATE KEY 触发了隐式分配
即使 AUTO_INCREMENT 已设为 100，如果执行 INSERT IGNORE INTO table_name (id, name) VALUES (99, 'test');，MySQL 仍会尝试分配 99 —— 成功后，下次自增仍从 100 开始；但如果该行因主键冲突被忽略，内部计数器仍可能被“预占”一次（尤其在较老版本中），导致后续插入跳号。
- 避免显式指定
id值插入，除非真需要覆盖 - 批量插入时慎用
INSERT ... ON DUPLICATE KEY UPDATE，它也可能干扰自增逻辑 - 查看是否发生过失败的自增尝试：
SHOW STATUS LIKE 'Auto_inc%';（关注Auto_increment_offset和Auto_increment_increment是否被意外修改）
在主从复制环境下修改 AUTO_INCREMENT 要格外小心
主库执行 ALTER TABLE ... AUTO_INCREMENT 会写入 binlog，从库重放时若已有更大 ID 的数据，可能触发主键冲突或跳号。更危险的是，如果从库上手动改了 AUTO_INCREMENT，而主库又插入新记录，极易造成 ID 冲突。
- 主从环境中，优先通过应用层控制 ID 分配逻辑（如用雪花算法），而非依赖 MySQL 自增
- 必须调整时，在低峰期停写、确认主从同步完成后再操作，并立刻验证从库
SHOW CREATE TABLE输出是否一致 - 避免在从库执行任何
ALTER TABLE ... AUTO_INCREMENT，除非你明确知道它不会被复制且已做好数据一致性兜底
真正麻烦的不是语法，而是自增 ID 在并发、复制、异常中断下的状态不确定性——哪怕只改一次，也得盯着 MAX(id)、SHOW CREATE TABLE 和 binlog_format 三处才敢放心。
