MySQL 5.7触发器中禁止对当前表执行SELECT MAX(id)或LAST_INSERT_ID()读取，因引擎硬限制报ERROR 1442；唯一可行方案是用独立计数表配合INSERT ON DUPLICATE KEY UPDATE与紧随其后的LAST_INSERT_ID()实现原子递增。
触发器里不能用 SELECT MAX(id) 或 LAST_INSERT_ID() 读当前表
MySQL 5.7 明确禁止在触发器中对触发它的表执行任何 SELECT，哪怕只是查个最大值：SELECT MAX(id) FROM orders 会直接报错 ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger。这不是权限或语法问题，是引擎级硬限制。很多人抄来的“BEFORE INSERT 中 SET NEW.sn = (SELECT COALESCE(MAX(sn), 0) + 1 FROM orders)”写法，一跑就崩。
同样，LAST_INSERT_ID() 在触发器里也无效——它只反映最近一次显式调用 INSERT、UPDATE 等语句产生的自增 ID，而触发器本身不产生新 ID，且无法在 BEFORE 阶段读取本行尚未生成的 NEW.id。
唯一可行方案：独立计数表 + INSERT ON DUPLICATE KEY UPDATE
必须把序列状态抽离到一张专用表，用 MySQL 原生支持的原子写机制更新。这张表结构极轻量，主键按业务维度（如日期、类型）设计：
CREATE TABLE seq_counter ( date_key CHAR(8) PRIMARY KEY, seq INT DEFAULT 0 );
触发器内关键逻辑如下（注意顺序不可乱）：
INSERT INTO seq_counter VALUES (DATE_FORMAT(NOW(), '%Y%m%d'), 1) ON DUPLICATE KEY UPDATE seq = LAST_INSERT_ID(seq + 1)- 紧接着立刻执行
SELECT LAST_INSERT_ID() INTO @next_seq——中间不能夹任何其他 SQL，否则LAST_INSERT_ID()被覆盖 - 再拼接业务号：
SET NEW.sn = CONCAT('ORD', DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(@next_seq, 4, '0'))
这个组合能扛住并发，因为 INSERT ... ON DUPLICATE KEY UPDATE 是原子操作，InnoDB 内部用行锁保证同一 date_key 下的递增不冲突。
为什么不能在触发器里跨表 UPDATE 或 SELECT FOR UPDATE
一旦触发器里出现 UPDATE stock SET qty = qty - 1 WHERE sku = NEW.sku，或者 SELECT qty FROM stock WHERE sku = NEW.sku FOR UPDATE，就极易引发死锁。日志里常看到 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: TABLE: `stock` —— 主事务锁了 orders 表某行，触发器又去锁 stock，另一条路径反着来，瞬间 deadlock。
正确做法是：
- 所有关联查询只允许基于唯一索引的单行查找，例如
SELECT config_value FROM sys_config WHERE key_name = 'order_timeout'（且key_name必须有唯一索引） - 绝对禁用
SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE MODE - 库存、积分等变更逻辑全部剥离出触发器，改由应用层异步处理或通过日志表（如
BLACKHOLE引擎）暂存后批量更新
容易被忽略的细节：会话级函数依赖与错误传播
LAST_INSERT_ID() 是会话级函数，只在当前连接内有效。如果触发器里先执行了别的 INSERT（比如写日志），再调用它，拿到的就是那个日志的 ID，不是计数器的值。必须确保计数器那条 INSERT ... ON DUPLICATE KEY UPDATE 是触发器中**最后一条可能影响该函数的语句**。
另一个隐形坑是错误处理：触发器内任何报错（如计数表不存在、字段超长、权限不足）都会导致整个 INSERT 回滚，但错误堆栈里往往只显示“Trigger failed”，真正根源藏在计数表操作里。上线前务必用并发压测验证，别只靠单条 SQL 测试。
