触发器中应使用new.id而非last_insert_id()，因后者返回连接级最近一次插入的id，不可靠；new.id在after insert中精确对应当前行，字段名须与表定义一致。
触发器里直接用 LAST_INSERT_ID() 是错的
在 AFTER INSERT 触发器中，LAST_INSERT_ID() 返回的不是当前这条记录的自增 ID，而是整个连接最近一次显式调用 INSERT ... VALUES 或 INSERT ... SELECT 时生成的 ID。如果触发器被批量插入、存储过程或其它并发操作干扰，结果完全不可靠。
真正安全的方式是使用 NEW.id（假设主键字段叫 id）——它在 AFTER INSERT 触发器中始终可用且精确对应当前行。
-
NEW在AFTER INSERT中可读，包含所有列值，包括刚生成的自增主键 - 字段名必须和表定义一致，比如主键是
user_id就得写NEW.user_id，不能硬编码为id - 如果表没定义主键或主键非自增，
NEW依然存在，但不会有“刚生成”的语义
为什么不能在 BEFORE INSERT 里用 NEW.id？
BEFORE INSERT 阶段，自增字段尚未分配值，NEW.id 是 NULL（除非你手动赋值）。此时想获取最终 ID 是徒劳的。
-
BEFORE INSERT只能修改NEW的值，不能“预测”数据库将分配什么 ID - 即使设了
NEW.id = 100，若表启用了自增且该字段未设NOT NULL或有默认值，仍可能被覆盖 - 唯一例外：显式插入具体值（如
INSERT INTO t(id) VALUES(123)），此时NEW.id就是 123，但已失去“自动生成”的前提
多行插入时，每个 NEW 都独立有效
哪怕执行的是 INSERT INTO t(name) VALUES('a'),('b'),('c')，触发器也会为每一行单独触发一次，每次的 NEW 都指向对应那条记录，NEW.id 各不相同。
- 无需循环或计数，MySQL 自动按行调用触发器
- 避免在触发器里查表反推 ID（比如
SELECT MAX(id) FROM t），这在并发下必然出错 - 如果要关联其他表写日志，直接用
INSERT INTO log_table (t_id, msg) VALUES (NEW.id, 'created')
注意存储引擎和事务边界
虽然 NEW.id 在 AFTER INSERT 中总是可用，但如果表用的是 MyISAM，且触发器里执行了另一张 InnoDB 表的更新，事务回滚时可能不一致。更隐蔽的问题是：如果触发器里抛出异常（比如 SIGNAL SQLSTATE '45000'），NEW.id 虽然能读到，但整条 INSERT 会被回滚，ID 实际未持久化。
- 不要把
NEW.id当作“已确认成功”的标志；它只是触发器执行时的快照值 - 跨引擎操作、复杂逻辑建议移到应用层，触发器只做轻量、确定性动作
- 测试时务必用真实并发场景验证，单线程跑通不代表生产安全
AFTER INSERT 就老老实实用 NEW.你的自增字段名。最常被忽略的，是字段名拼错、或者以为 LAST_INSERT_ID() 在触发器里也管用。
