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