INSERT触发器中安全访问新数据须用NEW.field显式引用字段，不可SELECT * FROM NEW或JOIN；BEFORE中可修改NEW字段以校验或补全数据，AFTER中仅读取；库存扣减需在BEFORE中结合行锁与条件判断防超卖，并用SIGNAL抛异常确保原子性。
INSERT 触发器里怎么安全访问新插入的订单数据
MySQL 的 BEFORE INSERT 触发器中，不能用 SELECT * FROM NEW；NEW 是一个行级引用，必须显式点出字段，比如 NEW.product_id、NEW.quantity。PostgreSQL 则用 NEW 作为记录变量，语法一致但需注意字段存在性——如果订单表里没有 product_id 字段，触发器会直接报错 column "product_id" does not exist。
常见错误是把 NEW 当成临时表去 JOIN，结果触发器编译失败。正确做法是把它当做一个带字段的结构体来取值。
库存扣减必须用 UPDATE … WHERE 加行锁防超卖
直接写 UPDATE products SET stock = stock - NEW.quantity WHERE id = NEW.product_id 看似简单，但并发插入同一商品时可能引发超卖——两个事务同时读到旧库存，各自减一次，就多扣了。
- 必须在
UPDATE语句末尾加AND stock >= NEW.quantity，确保扣减前库存充足 - 执行后要检查
ROW_COUNT()（MySQL）或GET DIAGNOSTICS（PostgreSQL），若为 0，说明库存不足，应抛出异常中断插入 - 推荐用
SELECT ... FOR UPDATE先锁定商品行，再更新，避免幻读干扰判断逻辑
触发器里抛异常让插入失败的写法差异
不同数据库中断流程的方式完全不同，写错会导致“扣了库存但订单没插进去”或“订单插进去了但库存没扣”这种状态不一致。
- MySQL：用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Insufficient stock' - PostgreSQL：用
RAISE EXCEPTION 'Insufficient stock for product %', NEW.product_id - SQL Server：用
THROW 50000, 'Insufficient stock', 1
注意：SQLite 不支持触发器内抛异常，只能靠应用层兜底校验，不适合高并发库存场景。
为什么不能在 AFTER INSERT 里扣库存
AFTER INSERT 触发器无法回滚主事务——一旦订单已写入，库存扣减失败，订单就滞留在库中，形成脏数据。而 BEFORE INSERT 在事务提交前执行，天然支持原子性：库存扣成功，订单才插入；扣失败，整个 INSERT 被拒绝。
另一个坑是误用 AFTER 导致触发器递归调用：比如扣库存后又触发另一个更新日志的触发器，再间接修改订单表，可能触发自身，造成死循环。
真正难的是库存与订单跨库或分布式场景——这时触发器失效，得换消息队列+补偿事务。单机数据库里，BEFORE INSERT + 行锁 + 显式异常，就是最稳的那条路径。
