触发器不能直接查库存防超卖，须依赖应用层SELECT ... FOR UPDATE加锁后操作；必须在BEFORE INSERT中校验扣减后余额非负，且INSERT/DELETE/UPDATE需配对处理库存，并辅以幂等、对账等最终一致性机制。
触发器里不能用 SELECT ... FOR UPDATE
动态库存余额的核心是“写时校验”，但很多人在触发器里直接查当前库存做判断，结果发现并发下单时超卖——因为触发器执行期间其他事务也能改同一行，SELECT拿到的是快照，不是锁住的实时值。
正确做法是在触发器里依赖行级锁机制，而不是自己查。比如在 INSERT INTO order_items 的 BEFORE INSERT 触发器中，不主动查 stock 表，而是让业务 SQL 自己带上 SELECT ... FOR UPDATE 锁住对应商品行，再调用插入逻辑。
- 触发器本身不加锁，也不查表；它只做轻量校验（如数量是否为正、是否小于等于待扣减值）
- 真正防超卖靠应用层或存储过程里先锁库存行，再更新
- MySQL 8.0+ 支持在触发器里调用函数，但禁止执行显式事务控制语句（如
START TRANSACTION），也禁止SELECT ... FOR UPDATE
UPDATE stock SET balance = balance - NEW.quantity WHERE id = NEW.product_id
这是最常写的更新语句，看着没问题，但实际会漏掉关键约束：没检查扣减后是否为负。触发器里必须补上这个判断，否则库存变负数都拦不住。
示例错误写法：UPDATE stock SET balance = balance - NEW.quantity WHERE id = NEW.product_id —— 这条语句执行成功不代表业务合法。
- 应在
BEFORE INSERT触发器中用IF NEW.quantity > (SELECT balance FROM stock WHERE id = NEW.product_id)做预判 - 注意子查询不能引用正在被修改的表（即不能在
stock的触发器里查stock），所以得把库存查出来存到变量，或改用JOIN方式传入 - PostgreSQL 允许在触发器里查本表，MySQL 不行，这点容易踩坑
INSERT 和 DELETE 都要配对更新库存
只处理 INSERT 触发器，忽略 DELETE 或 UPDATE，会导致订单取消、修改数量时库存不回滚。
典型场景：用户下单后取消，如果没在 AFTER DELETE 触发器里加回库存，余额就永远少了。
-
AFTER INSERT：扣减库存 -
AFTER DELETE：加回库存（前提是订单状态允许退款/取消） -
BEFORE UPDATE：先按原数量加回，再按新数量扣除（避免中间态超卖） - 别忘了检查订单状态字段，比如只有
status = 'cancelled'才回滚库存，否则可能误加
触发器无法替代应用层幂等和最终一致性校验
触发器能保证单次 DML 操作的原子性，但没法解决网络重试、消息重复消费、跨库操作等问题。比如 MQ 推送两次扣库存指令，触发器会执行两次，照样超卖。
真实系统里，触发器只是第一道防线，后面还得靠应用层唯一键（如 order_id + item_id）、状态机流转、定时对账任务来兜底。
- 数据库唯一索引可以防重复插入，但不能防逻辑重复（比如两个不同
order_id扣同一商品） - 高并发下建议把库存扣减下沉到 Redis + Lua 做原子操作，数据库触发器只做最终落库和对账用
- 记得给
stock表加version字段或时间戳，方便对账时识别异常更新
触发器不是银弹，它只管“这一行怎么改”，不管“为什么改”“改对了没有”。越想靠它包打天下，后期越难排查负库存到底是哪笔订单漏锁、哪次取消没回滚、哪条消息被重放。
