自增字段最核心的作用：省事 + 保唯一
它不是“必须用”，而是“不用就得多写、多想、多错”。比如插入用户时，你不想每次手动算下一个
id是多少，也不希望两个人同时插入时撞上同一个
id。MySQL 把这事包圆了：只要字段设了
AUTO_INCREMENT，你 INSERT 时不填它、填
NULL或填
0，它就自动给一个没用过的整数。
这背后其实靠的是两个硬约束：
PRIMARY KEY（或
UNIQUE）+ 整数类型（
INT、
BIGINT）。缺一不可——没主键，MySQL 不让你加自增；用了
VARCHAR，直接报错。
为什么删了数据，自增值却不回退？
这是最常被误解的一点：自增不是“当前最大值 + 1”，而是“下一个可用值”。删除某条记录，比如删掉
id = 5，表里剩下
1,2,3,4,6，下一次插入仍会是
7，不是
5。
DELETE FROM table只删数据，不动自增值
TRUNCATE TABLE table会重置自增值（回到初始值，通常是 1） 真要保留数据又想重置？只能两步走：
DELETE后接
ALTER TABLE table AUTO_INCREMENT = 1
注意：
TRUNCATE是 DDL 操作，不能回滚；而
DELETE是 DML，可回滚但不重置自增——哪怕整个事务 rollback 了，自增值也已悄悄涨过一轮。
实际建表和修改时的硬性限制
不是所有字段都能“后来加”自增，也不是所有场景都适合用。常见卡点如下：
一张表最多只能有一个AUTO_INCREMENT字段 已有数据的表加自增，必须先确保该列无重复值、无 NULL（否则
MODIFY COLUMN会失败） 如果原表已有主键，得先
DROP PRIMARY KEY，再
MODIFY字段并加回
PRIMARY KEY
BIGINT比
INT更安全：21 亿上限对订单/日志类表太容易触顶，溢出后插入直接报错
ERROR 1467 (HY000)
示例：给已有表
logs的
id列补自增主键（假设它当前是普通 INT 且无重复）：
ALTER TABLE logs MODIFY id BIGINT NOT NULL AUTO_INCREMENT FIRST; ALTER TABLE logs DROP PRIMARY KEY, ADD PRIMARY KEY (id);
高并发或分布式环境下，自增主键容易出什么问题？
单机 MySQL 下它很稳；但一旦涉及分库分表、多写节点、或需要 ID 全局有序，
AUTO_INCREMENT就会暴露本质：它是本地生成、无协调、不保证连续也不保证全局唯一。 主从切换后，如果从库曾被写入，可能产生重复
id双主架构中，若未调大
auto_increment_increment和错开
auto_increment_offset，必然冲突 微服务多实例直连不同 MySQL 实例时，ID 段天然重叠，合并数据或做关联查询会出错
这时候别硬扛，该换就换：用
UUID、
ULID、雪花算法（Snowflake）生成的
BIGINT，或者干脆让应用层负责发号。自增只适合“单写、可控、不要求跨系统唯一”的场景。
真正容易被忽略的，是它和事务、锁、引擎版本的耦合——比如 MySQL 5.7 重启后自增值会重算，而 8.0 之后才真正持久化进 redo log。线上升级前，务必确认这个行为是否影响你的业务逻辑。
