在AFTER INSERT触发器中，NEW.id是刚插入行的真实自增ID；BEFORE INSERT中NEW.id为NULL，不可用；LAST_INSERT_ID()在触发器中不绑定当前行，仅反映连接级最近一次自增插入值。
触发器里不能直接用 LAST_INSERT_ID() 获取新插入行的 ID
在 INSERT 触发器中，LAST_INSERT_ID() 返回的是**整个连接最近一次显式调用 INSERT ... VALUES 或 INSERT ... SELECT 产生的自增 ID**，而不是当前触发器正在处理的那条记录的 ID。如果触发器执行前有其他语句（比如日志表插入、临时表操作）改写了该值，就完全不可靠。
真正可用的方式是：在 BEFORE INSERT 触发器中，NEW.id 是空的（因为自增 ID 还没生成）；但在 AFTER INSERT 中，NEW.id 已被 MySQL 自动赋值，可安全使用。
-
AFTER INSERT触发器中，NEW.id就是刚插入行的真实自增 ID -
BEFORE INSERT中，NEW.id为NULL（除非你手动设了一个非 0 值，但会绕过自增逻辑） - 不要在触发器里调用
SELECT LAST_INSERT_ID()—— 它不绑定当前行，只绑定连接上下文
AFTER INSERT 触发器中正确引用自增 ID 的写法
假设有一张用户表 users(id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50))，你想在插入后自动往日志表写入 ID 和时间：
CREATE TRIGGER tr_users_after_insert AFTER INSERT ON users FOR EACH ROW BEGIN INSERT INTO user_logs(user_id, created_at) VALUES (NEW.id, NOW()); END;
注意这里必须用 AFTER INSERT，且直接取 NEW.id。如果误写成 BEFORE INSERT，NEW.id 是 NULL，会导致外键失败或默认值被写入。
- 仅限单行插入场景：MySQL 触发器是逐行触发的，
NEW始终指向当前这一行 - 批量插入（如
INSERT INTO ... VALUES (...), (...)）也会为每一行分别触发一次AFTER INSERT，所以NEW.id每次都准确 - 若表主键不是自增字段（比如 UUID），
NEW.id仍是可用的，只是它来自显式赋值而非自动生成
想在 BEFORE INSERT 中预知自增 ID？基本做不到
MySQL 不提供“预测下一个自增 ID”的安全机制。虽然可以通过 SELECT AUTO_INCREMENT FROM information_schema.TABLES 查当前计数器，但它在并发插入下极不可靠：
- 查到的值可能已被其他事务占用
- 自增锁释放时机与事务隔离级别有关，无法保证一致性
- 即使你用
INSERT ... SELECT+LOCK TABLES强行串行化，也违背了高并发设计原则
真正需要“提前知道 ID”时，应换思路：比如先用 INSERT INTO ... VALUES () 插一条空记录获取 ID，再用该 ID 更新其他字段 —— 但这已不属于触发器能解决的范畴，得由应用层控制。
UPDATE 或 DELETE 触发器中怎么拿 ID？
和 INSERT 不同，UPDATE 和 DELETE 触发器中的 OLD.id 始终有效，因为原记录已存在：
-
BEFORE UPDATE/AFTER UPDATE：可用OLD.id（更新前的 ID）、NEW.id（更新后的 ID，若 ID 字段允许修改） -
BEFORE DELETE/AFTER DELETE：只有OLD.id可用，NEW不存在 - 注意：如果表用的是复合主键，
OLD和NEW都包含全部主键字段，按定义引用即可
自增 ID 在触发器里从来不是“神秘值”，它就在 NEW 或 OLD 里，关键是你选对了触发时机。最容易出错的地方，就是把 BEFORE INSERT 当成能拿到 ID 的地方 —— 实际上，那一刻它还不存在。
