最稳妥方式是在CREATE TABLE时直接定义AUTO_INCREMENT配合PRIMARY KEY；必须为整数类型且NOT NULL，需被PRIMARY KEY或UNIQUE索引覆盖，一个表仅允许一个自增字段，起始值由MAX(id)+1或指定值较大者决定。
直接在 CREATE TABLE 语句里定义 AUTO_INCREMENT 并配合 PRIMARY KEY，是最稳妥、最常用的方式。其他方式（比如先建表再改）容易踩坑，尤其当表已有数据时。
创建表时直接声明自增主键
这是唯一不需要额外校验、不依赖当前表状态的做法。MySQL 在建表阶段就完成元数据初始化，不会触发任何冲突检查。
关键点：
-
AUTO_INCREMENT必须和PRIMARY KEY（或UNIQUE）同时存在，不能单独加 - 字段必须是整数类型（
TINYINT、INT、BIGINT等），且隐式或显式声明NOT NULL - 一个表只能有一个
AUTO_INCREMENT字段
示例：
CREATE TABLE users ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(50) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB;
也可以把 PRIMARY KEY 写在列定义里，效果一样：
CREATE TABLE orders ( order_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, amount DECIMAL(10,2) );
为什么不能先建表再加自增主键？
对已有数据的表执行 ALTER TABLE ... ADD COLUMN id INT AUTO_INCREMENT PRIMARY KEY FIRST，大概率失败——除非该表原本没有主键、且你要加的列当前为空（或全为 NULL），否则会报错：
ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key
或
ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY'
原因很直接：MySQL 要求自增字段在填充时必须能生成**全局唯一值**，而它默认从 1 开始填；如果表里已有 100 行数据，它没法自动判断你希望新 id 是 1~100 还是 101 起步，更没法保证不和现有业务字段冲突。
所以「先建表再加自增主键」只适用于空表，或你愿意手动处理所有已有行的 id 值（比如用 ROW_NUMBER() 或变量赋值）。
设置自增起始值的正确时机
AUTO_INCREMENT 的初始值不是在建表语句里靠参数控制的，而是由 MySQL 自动推导：空表从 1 开始；非空表取 MAX(id) + 1（InnoDB 8.0+ 持久化保存，5.7 及以前重启后重新扫描）。
如果你想指定起始值，必须在建表后、插入数据前执行：
ALTER TABLE users AUTO_INCREMENT = 1001;
但注意：这个值不能小于当前表中最大 id 值，否则插入时会报主键冲突。例如表里已有 id = 1005 的记录，你设成 1001 就无效。
常见误操作：
- 在有数据的表上建完自增主键后立刻
ALTER TABLE ... AUTO_INCREMENT = 1→ 必然失败 - 用
INSERT ... SELECT批量导入时没关自增校验 → 可能跳号或报错
插入数据时不指定自增字段的行为
只要字段定义了 AUTO_INCREMENT 且是主键，插入时省略该字段，MySQL 就会自动填值：
INSERT INTO users (name) VALUES ('alice'), ('bob');
结果：id 分别为 1 和 2（假设起始值是 1）。
但要注意两个边界情况：
- 显式插入
0或NULL，等价于“不指定”，仍走自增逻辑 - 显式插入一个大于当前自增值的数（如当前是 5，你插
id = 100），MySQL 接受，并把下一次自增值设为101；但如果插的是3，则下一次还是从6开始（不会回退）
真正容易被忽略的是：事务回滚、唯一键冲突、批量插入中途失败，都会导致自增值“跳号”——这不是 bug，是 InnoDB 的正常行为，且无法回滚自增计数器本身。
