必须使用 before update 触发器,因其能在写入前校验 new.stock 防止负数;after update 无效,myisam 不支持回滚,并发下易超卖;check 约束在 mysql 8.0+ 有效但有局限,复杂逻辑仍需触发器或应用层兜底。

必须用 BEFORE UPDATE,不能用 AFTER
AFTER UPDATE 触发器根本拦不住负数写入——数据已经落盘。哪怕你里面写 SIGNAL 抛错,NEW.stock 也早就存进去了。InnoDB 下事务可能回滚,但 MyISAM 完全无效;更麻烦的是并发场景:两个请求同时读到 10 库存,都判断“扣 8 没问题”,结果先后执行,库存变成 -6。所以校验动作必须卡在写入前,只认 BEFORE UPDATE。
校验目标是 NEW.stock,不是 OLD.stock 减什么量
常见错误是写成 IF OLD.stock - 10 ——这硬编码了扣减量,实际业务里扣多少来自订单字段、参数或计算逻辑,根本不确定。触发器要通用,就得直接看最终要写进去的值:<code>NEW.stock。只要它
- 正确写法:
IF NEW.stock - 错误写法:
IF OLD.stock - @amount (@amount 不一定存在,也不一定可靠) - 别试图在触发器里重新算扣减量,那是应用层该干的事
CHECK 约束比触发器更轻量,但有版本限制
MySQL 8.0.16+ 支持原生 CHECK 约束,比如建表时加 stock INT CHECK (stock >= 0)。它比触发器性能好、语法简、自动生效。但注意:
- MySQL 5.7 及更早版本不支持
CHECK(会被解析但忽略) - 即使 8.0+,某些旧迁移数据可能绕过约束(如
LOAD DATA INFILE加IGNORE) -
CHECK只能做简单表达式校验,没法关联查其他表或调用函数
所以生产环境建议:新项目优先用 CHECK,老版本或需要复杂逻辑(比如扣减前查预占库存)才上触发器。
触发器只守本表,跨表扣减得靠应用层兜底
如果库存分散在 products、warehouse_stock、shop_inventory 多张表,单个触发器只能保 products.stock 不负,拦不住其他表被单独扣成负数。这时候触发器只是最后一道防线,不是万能锁。真正要防超卖,得在应用层统一走库存服务,用分布式锁 + 预占 + 最终一致性校验,数据库触发器只负责“绝不让本表字段落地为负”这个底线。











