MySQL触发器中BEFORE INSERT不能用SELECT MAX(id)补ID，因引擎级限制会报错；AFTER INSERT可安全使用NEW.id；AUTO_INCREMENT原生机制已满足自动填ID需求，无需触发器。
BEFORE INSERT 里不能用 SELECT MAX(id) 补 ID
MySQL 明确禁止在触发器中对当前表执行任何 SELECT（包括 MAX(id)），否则会报错：ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger...。这不是语法问题，而是引擎级限制——触发器运行时表已被语句锁定，不能再读。
常见错误写法：
CREATE TRIGGER trg_fill_id BEFORE INSERT ON users FOR EACH ROW BEGIN SET NEW.id = (SELECT COALESCE(MAX(id), 0) + 1 FROM users); -- ❌ 直接报错 END;
- 别指望靠查询“当前最大值+1”来模拟自增逻辑
- 哪怕加了
WHERE id < (SELECT MAX(id) FROM ...)也一样被拦 - 唯一绕过方式是改用外部计数器表（如
seq_table），但引入额外锁和事务复杂度
AFTER INSERT 中直接用 NEW.id 拿 ID 最可靠
只要主键定义为 AUTO_INCREMENT，且插入时没显式指定该字段（比如传 NULL 或省略字段），MySQL 就会在写入前生成 ID，并注入到触发器的 NEW 上下文中。
示例（记录日志）：
CREATE TRIGGER log_user_insert AFTER INSERT ON users FOR EACH ROW BEGIN INSERT INTO user_log (user_id, action, created_at) VALUES (NEW.id, 'INSERT', NOW()); -- ✅ 安全可用 END;
-
BEFORE INSERT中NEW.id是只读的，不能赋值（除非你主动放弃自增） -
AFTER INSERT中它已确定，可用于关联插入、通知、缓存更新等 - 如果主键字段名叫
user_id，就得写NEW.user_id，不能硬编码id - 事务回滚后，
NEW.id值仍有效，但该 ID 已被消耗，下次插入会跳号
想“插入时不传 ID 却自动填上”，根本不需要触发器
这是对 AUTO_INCREMENT 的误用。原生机制已完全覆盖该需求：
- 建表时确保主键带
AUTO_INCREMENT：例如id INT PRIMARY KEY AUTO_INCREMENT - 插入时留空或传
NULL：INSERT INTO users (name) VALUES ('Alice')或INSERT INTO users (id, name) VALUES (NULL, 'Bob') - 若想允许传
0也触发自增，需关闭NO_AUTO_VALUE_ON_ZERO（不推荐，破坏语义） - 强行用触发器“补 ID”会破坏并发安全，且无法处理两个事务同时计算出相同 ID 的冲突
跨表关联插入时，别在触发器里查父表 ID
如果你的真实场景是“先插父表，再用它的 ID 插子表”，那应该把逻辑放在应用层或存储过程中，而不是触发器里。触发器不是事务协调器。
正确做法（SQL Server 示例）：
BEGIN TRANSACTION;
INSERT INTO ParentTable (name) VALUES ('parent');
DECLARE @ParentID INT = SCOPE_IDENTITY(); -- ✅ 当前作用域最后一个 ID
INSERT INTO ChildTable (parent_id, note) VALUES (@ParentID, 'child');
COMMIT;-
SCOPE_IDENTITY()比@@IDENTITY更安全，避免触发器干扰 - MySQL 对应的是
LAST_INSERT_ID()，但它只在当前连接有效，且受并发影响 - 触发器内去查刚插入的父表 ID，等于又踩了一次“不能查当前表”的坑
最易被忽略的一点：触发器里的 NEW.id 看似简单，但它依赖于表结构定义和插入方式的严格匹配——漏掉 AUTO_INCREMENT、显式传了 0、或用了 INSERT ... SELECT 批量插入，都可能导致 NEW.id 不是你以为的那个值。
