MySQL行级触发器中，BEFORE UPDATE触发器可直接用OLD.quantity获取更新前真实库存值，无需额外查询，该值可靠且原子；防扣减超限应判断OLD.quantity - NEW.quantity ≥ 0。
MySQL行级触发器无法在UPDATE中读取被修改行的旧值？
不能直接用 OLD.quantity 做判断——MySQL的 BEFORE UPDATE 触发器里，OLD 是只读的，但你真正需要的是「更新前库存是否足够」。关键是：触发器执行时，该行已被加行锁（由外层 UPDATE 语句持有），所以只要逻辑写对，能保证原子性。
常见错误是试图在触发器里再查一次表（比如 SELECT quantity FROM stock WHERE id = NEW.id），这不仅多余，还可能引发死锁或幻读（尤其在 READ COMMITTED 下）。正确做法是直接用 OLD.quantity 和 NEW.quantity 做差值判断。
-
OLD.quantity是当前行更新前的真实库存值（可靠） - 你要防的是「扣减量 > 当前库存」，即：
OLD.quantity - NEW.quantity - 触发器必须用
BEFORE UPDATE，且在发现超卖时用SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Insufficient stock'中断操作
如何写一个安全的库存扣减触发器（含事务一致性）
假设表结构是 stock(id INT PRIMARY KEY, quantity INT NOT NULL)，业务侧执行的是类似 UPDATE stock SET quantity = quantity - 1 WHERE id = 123 的语句。触发器要拦截所有导致 quantity 的更新。
NEW.quantity
- 如果业务用
SET quantity = quantity - 1，MySQL 会在触发器执行前完成计算，NEW.quantity就是扣减后的值 - 不推荐在触发器里重新计算差值（如
OLD.quantity - (OLD.quantity - 1)），冗余且易错 - 该触发器不阻止并发 UPDATE 同一行——但 MySQL 行锁已保证同一行不会并行进入触发器，天然串行化
为什么不用存储过程+SELECT FOR UPDATE替代？
很多人想到先 SELECT quantity FROM stock WHERE id = ? FOR UPDATE，再判断、再 UPDATE。这确实可行，但多一次网络往返和额外事务开销。而触发器方案把校验压进单条 UPDATE，更轻量。
但要注意边界：触发器只管「单行」，它不解决分布式场景或跨表库存（比如订单明细 + 库存主表分离）的问题。如果你的扣减涉及多个商品ID，或者要同时更新订单状态，那必须用显式事务+ SELECT ... FOR UPDATE 控制范围。
- 触发器对批量 UPDATE（如
UPDATE stock SET quantity = quantity - 1 WHERE id IN (1,2,3)）依然有效，每行单独触发 - 但如果批量中某行库存不足，整条 UPDATE 会失败，不会部分成功——符合业务预期
- MySQL 8.0+ 支持触发器里调用存储函数，但别在里面做复杂查询或远程调用，会拖慢锁持有时间
容易忽略的隔离级别与调试陷阱
在 READ COMMITTED 或更低隔离级别下，触发器看到的 OLD.quantity 是事务开始时的快照值，不是最新提交值——但没关系，因为行锁已阻塞其他事务修改该行，实际不会出现脏读。
真正容易踩的坑是测试时没开事务，或者用客户端工具（如 MySQL Workbench）手动执行 UPDATE，结果发现触发器没生效——检查是否漏了 DELIMITER，或触发器创建后没刷新元数据（FLUSH TABLES 不必要，但改表结构后需确认触发器状态）。
- 用
SHOW TRIGGERS LIKE 'stock'确认触发器存在且Timing是BEFORE - 错误信息中的
SQLSTATE '45000'是通用未定义异常，应用层需捕获并解析MESSAGE_TEXT - 不要依赖触发器记录日志（如
INSERT INTO log_table），除非日志表也是事务内且同引擎，否则可能破坏原子性
触发器本身不解决高并发下的性能瓶颈，只是把校验逻辑下沉。真正的压力点在行锁等待上——如果某个热商品被频繁争抢，锁冲突会变多，这时得考虑分库分表或缓存预占。
