自增字段核心作用是省事和保唯一，依赖PRIMARY KEY或UNIQUE约束及整数类型；删除数据不重置自增值，TRUNCATE才重置；高并发或分布式场景易冲突，需换用UUID、雪花算法等方案。
自增字段最核心的作用：省事 + 保唯一
它不是“必须用”，而是“不用就得多写、多想、多错”。比如插入用户时，你不想每次手动算下一个 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。线上升级前，务必确认这个行为是否影响你的业务逻辑。
