必须使用 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 不负，拦不住其他表被单独扣成负数。这时候触发器只是最后一道防线，不是万能锁。真正要防超卖，得在应用层统一走库存服务，用分布式锁 + 预占 + 最终一致性校验，数据库触发器只负责“绝不让本表字段落地为负”这个底线。
