应直接在触发器中用select...into或子查询比较，如if (select stock from goods where id = new.goods_id)

触发器里怎么判断库存是否够扣？

核心是读取当前库存值，和待扣减数量比大小。不能只查 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 的直接写权限），不能全指望触发器。