必须用BEFORE UPDATE触发器校验NEW.stock是否小于0，因AFTER UPDATE数据已写入无法拦截；CHECK约束在MySQL 8.0.16+更轻量但有版本和功能限制，跨表库存仍需应用层兜底。
BEFORE UPDATE 是唯一能拦住负库存的触发器时机
用 AFTER UPDATE 触发器检查 NEW.stock 纯属无效——数据已经写进磁盘，哪怕你 SIGNAL 抛错，负数也落库了。InnoDB 事务虽可回滚，但 MyISAM 完全不支持，且并发下两个请求同时读到库存 10、都判断“扣 8 没问题”，结果先后提交，库存直接变 -6。
真正起作用的只有 BEFORE UPDATE：它在数据落盘前拦截，校验目标必须是 NEW.stock（即将写入的值），而不是靠 OLD.stock - @amount 这类硬编码计算——业务里扣多少来自订单字段或参数，根本不确定。
- 错误写法：
IF OLD.stock - 10 < 0 THEN SIGNAL ... - 正确写法：
IF NEW.stock < 0 THEN SIGNAL ... - 别在触发器里重新算扣减量，那是应用层该干的事
触发器不能碰正在被更新的表
在 orders 表上建触发器去 UPDATE inventory 看似合理，但 MySQL 会直接报错 ERROR 1442：“Can't update table 'inventory' in stored function/trigger because it is already used by statement...”。触发器里操作的目标表，绝不能是当前正被 UPDATE、INSERT 或 DELETE 的那张表本身。
安全路径只有一条：让触发器作用于库存表（如 inventory）或关联表（如 order_items），且确保逻辑不反向触碰原表。
- 订单确认扣库存？在
order_items上建AFTER UPDATE触发器，用WHERE product_id = NEW.product_id精确更新 - 订单插入扣库存？改用
BEFORE INSERT，配合SELECT ... FOR UPDATE加锁查库存，再UPDATE inventory - 绝对禁止在触发器里写
UPDATE orders或INSERT INTO orders
CHECK 约束比触发器更轻量，但别高估它的能力
MySQL 8.0.16+ 支持原生 CHECK (stock >= 0)，语法简、性能好、自动生效，比触发器更适合做底线防护。但它有硬伤：
- MySQL 5.7 及更早版本会忽略
CHECK（解析但不执行） -
LOAD DATA INFILE ... IGNORE可能绕过约束 - 无法关联查其他表，也不能调用函数，纯表达式校验
所以生产环境建议：新项目优先加 CHECK，老版本或需复杂逻辑（比如扣减前查预占库存）才上触发器。别指望它替代应用层校验。
触发器只守本表，跨表库存得靠应用层兜底
如果库存分散在 products、warehouse_stock、shop_inventory 多张表，单个触发器只能保 products.stock 不负，拦不住其他表被单独扣成负数。这时候触发器只是最后一道防线，不是万能锁。
真正防超卖，得在应用层统一走库存服务，用分布式锁 + 预占 + 最终一致性校验。数据库触发器只负责“绝不让本表字段落地为负”这个底线——这点容易被忽略，但恰恰是最关键的边界。
