MySQL 5.7触发器中禁止SELECT ... FOR UPDATE，因其不支持显式加锁；防超卖应使用BEFORE INSERT触发器做库存快照校验，并配合同一事务内的条件UPDATE stock=stock-? WHERE id=? AND stock>=?实现原子扣减。
触发器里不能用 SELECT ... FOR UPDATE
MySQL 5.7 的触发器（BEFORE INSERT 或 BEFORE UPDATE）执行时，当前事务尚未真正开始写入，且触发器内部不支持显式加锁语句。你如果在触发器里写 SELECT stock FROM products WHERE id = NEW.product_id FOR UPDATE，会直接报错：ERROR 1362 (HY000): Statement not allowed in a stored function or trigger。这不是语法写错了，是 MySQL 强制限制——触发器里禁止任何带锁的读操作。
所以别想着靠触发器“先查再扣”，这条路在 5.7 里根本走不通。
真正能用的方案：BEFORE UPDATE + 条件校验
防超卖的核心不是“查库存”，而是“确保扣减后库存 ≥ 0”。这个判断可以在 BEFORE UPDATE 触发器里用纯表达式完成，不涉及额外查询，也不需要锁。
- 假设订单表
orders插入时带product_id和quantity，库存存在products表的stock字段 - 在
orders上建BEFORE INSERT触发器，对关联商品做库存校验 - 触发器内用
(SELECT stock FROM products WHERE id = NEW.product_id) - NEW.quantity 判断是否超卖 - 若为真，用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Insufficient stock'中断插入
注意：SELECT ... FROM products 在触发器里是允许的，只要不加 FOR UPDATE 或 LOCK IN SHARE MODE；但它是快照读，不保证并发安全——所以必须配合外层事务的隔离级别和更新逻辑。
必须搭配事务 + UPDATE 语句才真正原子
光有触发器不够。用户下单本质是两个动作：扣库存、记订单。触发器只拦住了非法订单，但库存没变。真正扣减还得靠应用层或存储过程发起 UPDATE products SET stock = stock - ? WHERE id = ? AND stock >= ?。
- 这个
UPDATE必须和INSERT INTO orders在同一个事务里 - WHERE 条件里的
stock >= ?是关键，它让 UPDATE 变成原子条件更新：成功则行数影响为 1，失败为 0 - 应用层检查
ROW_COUNT()，为 0 就说明库存已被其他事务抢走，需回滚并重试 - 事务隔离级别建议用
READ COMMITTED，避免间隙锁干扰高并发扣减
触发器只是“守门员”，真正的“扣减+防超卖”原子性由这个带条件的 UPDATE 语句保证。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
为什么不用 AFTER INSERT + UPDATE？
有人想在 AFTER INSERT 里去更新库存，这会导致逻辑漏洞：订单已落库，但库存更新失败（如唯一键冲突、网络中断），最终出现“有单无货”。而且 AFTER 触发器无法阻止插入本身，失去拦截意义。
更严重的是：如果多个事务同时 INSERT 同一商品，它们的 AFTER 触发器会并发执行 UPDATE products，而没有前置校验，就可能绕过库存判断——比如两个事务都读到 stock=10，各自扣 8，结果变成 stock=-6。
所以必须把校验放在 BEFORE 阶段，把扣减放在同一事务的显式 UPDATE 中，顺序不能颠倒。
触发器本身不解决并发问题，它只是语法层面的校验钩子；真正的防超卖能力，藏在那个带 WHERE stock >= ? 的 UPDATE 语句里，以及你有没有把它和订单插入包进同一个事务。
