触发器中可用new.id直接获取自增id，前提是主键设为auto_increment且插入时未显式指定该值；before insert中只读，after insert中可用于关联操作；事务回滚不影响触发器内已读取的new.id，但id已被消耗不可复用。
触发器里直接用 NEW.id 就能拿到自增 ID
只要表的主键是 AUTO_INCREMENT，且插入时没显式指定该字段值（比如传 NULL 或留空），MySQL 在执行 INSERT 时就会生成新 ID，并在触发器中通过 NEW.id 立刻可访问。这个值不是“查出来”的，而是 MySQL 在写入前就计算好、注入到 NEW 上下文里的。
常见错误是误以为要先查再用——比如在 BEFORE INSERT 触发器里写 SELECT LAST_INSERT_ID()，这会返回 0 或上一条连接的 ID，完全不可靠。
-
BEFORE INSERT中NEW.id是只读的，不能修改（除非你故意绕过自增逻辑） -
AFTER INSERT中NEW.id可安全用于插入关联表、记录日志等操作 - 如果表用的是复合主键或非标准自增字段名（比如叫
user_id），就得写成NEW.user_id，不能硬编码id
NEW.id 在事务回滚后还有效吗
有效，但仅限当前触发器上下文内。触发器是在语句执行过程中运行的，NEW 是语句生成的“拟插入行”快照，哪怕后续事务回滚，触发器内部已经读到的 NEW.id 不会变。
但要注意：这个 ID 已经被消耗了。即使插入最终失败，自增值也不会退回——下次成功插入时，ID 会跳号。所以别指望靠 NEW.id 做幂等判断或重试依据。
- 唯一键冲突、主键重复、触发器抛异常等导致插入失败时，
NEW.id仍能取到，但对应行并未落库 - 如果触发器里用
NEW.id去更新另一张表，而主表插入失败，就会出现“日志写了但主数据没写”的不一致 - 想强一致性？得把主表插入和关联操作包进同一个事务，别依赖触发器跨表写入
为什么有时候 NEW.id 是 NULL
只有三种情况：INSERT 显式指定了主键值、表没设 AUTO_INCREMENT、或者字段名对不上。
最典型的是建表时忘了加 AUTO_INCREMENT 属性，或者用了 INSERT INTO t (id, name) VALUES (123, 'x') 这种写法——此时 MySQL 直接用你给的值，不走自增逻辑，NEW.id 就是你传的 123，不是新生成的。
- 检查建表语句：确认字段定义含
INT PRIMARY KEY AUTO_INCREMENT，且没带NOT NULL冲突 - 检查插入语句：确保没在
VALUES里显式填了主键列（包括用0或DEFAULT） - 检查触发器时机：必须是
INSERT触发器，UPDATE或DELETE里NEW.id没意义
对比 LAST_INSERT_ID() 和 NEW.id 的适用场景
NEW.id 是触发器专属、零延迟、无需额外查询；LAST_INSERT_ID() 是连接级函数，适合应用层或存储过程里取刚插完的 ID。
两者根本不在一个维度：前者是行级上下文变量，后者是会话级状态函数。混用容易出错——比如在触发器里调 LAST_INSERT_ID()，返回的可能是上一条语句的 ID，而不是当前这条的。
- 在触发器中一律用
NEW.id，别绕弯 - 在应用代码或存储过程中插入后要取 ID，用
SELECT LAST_INSERT_ID()，且必须紧接在INSERT后执行 -
@@IDENTITY已过时，行为不稳定（受触发器内插入影响），不要用
NEW.id 看似简单，但前提是插入动作真走了自增流程。很多问题其实出在建表或 SQL 写法上，而不是触发器本身。
