触发器中直接用NEW.id可获取自增ID，前提是主键为AUTO_INCREMENT且插入时未显式指定该值；BEFORE INSERT中只读，AFTER INSERT中可用于关联操作；事务回滚后NEW.id仍有效但ID已被消耗不可复用。
触发器里直接用 NEW.id 就能拿到自增 ID
只要表主键是 AUTO_INCREMENT，且插入时没显式指定该字段值（比如传 NULL 或压根不写），MySQL 就会在生成新行时把 ID 注入到 NEW 上下文里。这不是“查出来”的，是 MySQL 在写入前就计算好、直接塞进来的。
常见错误是误以为要先查再用——比如在 BEFORE INSERT 触发器里写 SELECT LAST_INSERT_ID()，这会返回 0 或上一条语句的 ID，完全不可靠。
-
BEFORE INSERT中NEW.id是只读的，不能改（除非你主动绕过自增逻辑） -
AFTER INSERT中才能安全用NEW.id做后续操作，比如插入日志或关联表 - 如果主键字段名不是
id（比如叫user_id），就得写成NEW.user_id，不能硬编码
AFTER INSERT 触发器中往关联表插入数据
这是最常用也最稳妥的场景：NEW.id 已确定，且当前行已落库，可放心用于外键引用。
示例：用户表插入后，自动往 user_profile 表插入默认配置：
CREATE TRIGGER trg_insert_profile AFTER INSERT ON users FOR EACH ROW BEGIN INSERT INTO user_profile (user_id, status, created_at) VALUES (NEW.id, 'active', NOW()); END;
- 必须用
AFTER INSERT，BEFORE阶段NEW.id还没生成，拿不到 - 不能在触发器里更新原表（如
UPDATE users SET ... WHERE id = NEW.id），MySQL 会报Can't update table 'users' in stored function/trigger - 如果关联表有唯一约束或外键，确保
NEW.id确实已写入，否则可能因事务未提交而失败（但实际中 InnoDB 的AFTER INSERT是在语句级提交后触发，一般没问题）
事务回滚时 NEW.id 还有效吗？ID 会被复用吗？
NEW.id 在触发器内始终有效，哪怕后续整个事务回滚了，触发器里已经读到的值不会变。但这个 ID 已被消耗——即使插入最终失败，自增值也不会退回。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
也就是说，下一次成功插入时，ID 会跳号。这点特别容易被忽略：
- 别指望用
NEW.id做幂等判断（比如“如果 ID 存在就不插入”），它不反映最终持久化状态 - 别在触发器里基于
NEW.id去查当前表（如SELECT * FROM users WHERE id = NEW.id），MySQL 禁止这种对本表的SELECT，会报ERROR 1442 - 高并发下 ID 跳号是常态，不是 bug；若业务强依赖连续 ID，说明设计本身有问题，应换思路（比如用单独序列表 +
INSERT ... ON DUPLICATE KEY UPDATE）
为什么不用 LAST_INSERT_ID() 或 MAX(id)？
在触发器里调用 LAST_INSERT_ID() 是错的：它返回的是“当前会话最后一次 INSERT 生成的 ID”，而触发器执行时，本条语句还没完成提交，它很可能还是上一条语句的值，甚至为 0。
MAX(id) 更危险：触发器内禁止对当前表做任何 SELECT，MySQL 直接报错 ERROR 1442，根本跑不起来。
- 有人试图在存储过程里封装“先插再查最大值”，本质是把问题转移到外面，但依然无法规避并发冲突和事务可见性问题
- 所有绕开
NEW.id的方案，都是在对抗 MySQL 的设计契约，代价是复杂度飙升、一致性难保 - 真正需要动态算序号的场景（比如带业务前缀的流水号），应该用独立计数表，而不是在触发器里硬刚
最易被忽略的一点：触发器里的 NEW.id 是“拟插入行”的快照，它和最终是否落库无关。你要依赖的是这个值本身，而不是它背后的数据状态。
