应直接在触发器中用SELECT...INTO或子查询比较，如IF (SELECT stock FROM goods WHERE id = NEW.goods_id) < NEW.num THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '库存不足'; END IF;
触发器里怎么判断库存是否够扣？
核心是读取当前库存值，和待扣减数量比大小。不能只查 SELECT stock FROM goods WHERE id = NEW.goods_id 后在应用层判断——触发器执行时必须原子性拦截。常见错误是写成 IF (SELECT stock FROM goods WHERE id = NEW.goods_id) ，这在高并发下可能因 MVCC 或间隙锁不生效，导致判空或误判。
正确做法是用 SELECT ... FOR UPDATE 显式加行锁（仅限 InnoDB），确保读取与后续更新之间不被其他事务干扰：
SELECT stock INTO @current_stock FROM goods WHERE id = NEW.goods_id FOR UPDATE;
再用 IF @current_stock 拦截。
INSERT 和 UPDATE 触发器都要写吗？
要。订单插入（INSERT INTO orders）和订单数量修改（UPDATE orders SET quantity = ...）都可能引发库存扣减，两者触发时机不同，必须分别建触发器。漏掉 UPDATE 触发器，用户改订单数量时就绕过校验。
注意：如果订单表本身有状态字段（如 status），还需判断是否为“已确认”类状态才扣库存，避免草稿订单误触发。典型条件是：IF NEW.status = 'confirmed' AND OLD.status != 'confirmed' THEN ...
-
INSERT触发器用BEFORE INSERT，在数据写入前拦截 -
UPDATE触发器用BEFORE UPDATE，且需对比OLD.quantity和NEW.quantity，只对增量部分校验（比如从 2 改成 5，实际只多扣 3） - 若支持取消订单，还得补
UPDATE触发器处理status从 confirmed → cancelled 的情况，反向加回库存
为什么不能在触发器里直接 UPDATE goods 表？
可以，但必须小心死锁和递归。常见错误是：在订单的 BEFORE INSERT 触发器里执行 UPDATE goods SET stock = stock - NEW.quantity WHERE id = NEW.goods_id —— 这会导致该行被再次加锁，而外层 INSERT 已持有意向锁，极易和并发事务形成循环等待。
更稳妥的做法是只做校验，把库存扣减交给主业务 SQL 完成（即校验通过后，应用层再发一条 UPDATE goods ...）。这样锁粒度可控，也方便配合事务回滚。
如果坚持在触发器内扣减，务必确保：
- 使用
SELECT ... FOR UPDATE后立即UPDATE，中间不穿插其他语句 - 避免在触发器中调用存储过程或函数，以防隐式开启新事务
- MySQL 8.0+ 要关掉
autocommit并显式控制事务边界，否则触发器内操作可能被自动提交，破坏一致性
触发器无法覆盖的边界场景有哪些？
触发器只响应 DML，对以下情况无能为力：
- 直接
UPDATE goods SET stock = -100（绕过订单表） - 批量导入订单（如
LOAD DATA INFILE）未启用触发器（MySQL 默认禁用） - 跨库操作（比如订单在
db_order，商品在db_goods），触发器无法跨库查询 - 使用
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE时，触发器行为与普通INSERT不同，容易漏校验
这些地方必须靠应用层兜底校验 + 权限管控（如限制 DBA 以外账号对 goods.stock 的直接写权限），不能全指望触发器。
