应使用 BEFORE UPDATE 触发器直接校验 NEW.quantity

BEFORE UPDATE 里直接用 NEW.quantity 判断是否为负

业务侧执行的 UPDATE stock SET quantity = quantity - 1 WHERE id = 123，MySQL 会在触发器执行前完成表达式计算，NEW.quantity 就是扣减后的目标值。所以校验逻辑非常直接：只要 NEW.quantity ，就说明这次更新会导致负库存。

常见错误是绕一圈去算差值（比如 OLD.quantity - (OLD.quantity - 1)），既冗余又容易因业务写法变化而失效。真正该拦住的是“最终结果为负”，不是“扣了多少”。

• 必须用 BEFORE UPDATE，否则无法中断写入
• 错误码统一用 SQLSTATE '45000'，便于应用层识别业务校验失败
• 不要在触发器里再查一遍表——NEW.quantity 已经是计算完毕、即将写入的值，可靠且高效

为什么不能只靠字段设为 UNSIGNED？

把 quantity 字段定义成 INT UNSIGNED 确实能在底层阻止负数写入，但报错信息是 ER_BAD_NULL_ERROR 或类似底层错误，客户端看到的是模糊的“Data truncated for column 'quantity'”，无法区分是恶意篡改、计算溢出还是业务逻辑错误。

更关键的是，UNSIGNED 只拦住负数，拦不住“扣太多”——比如当前库存是 5，却执行 SET quantity = quantity - 10，结果变成 4294967291（回绕），这在 MySQL 中是合法的 UNSIGNED 值，但业务上就是超卖。

• UNSIGNED 是数据类型约束，不是业务规则校验
• 它不提供可读错误信息，也不支持自定义提示（如商品 ID、所需数量）
• 和触发器不互斥，可以共存，但不能替代

并发更新同一行时，触发器还安全吗？

安全。MySQL 的行级锁机制保证了：当外层 UPDATE 语句开始执行，它会先对匹配的行加 X 锁；这个锁一直持有到事务结束。而触发器是在这个锁已持有的上下文中运行的，所以多个并发事务不会同时进入同一个 BEFORE UPDATE 触发器逻辑。

换句话说，触发器本身不负责加锁，它依赖外层 DML 的锁保障串行化。你不需要、也不应该在触发器里再写 SELECT ... FOR UPDATE——那反而可能引发死锁，尤其当触发器还涉及其他表时。

• 锁由 UPDATE 语句自动获取，触发器只是“锁内执行者”
• 如果业务用了 UPDATE ... WHERE id IN (1,2,3)，锁的是所有匹配行，触发器逐行执行，每行仍被独占
• 唯一风险点是应用层没开事务，或用了 AUTOCOMMIT=1，导致每个语句自成事务——这时锁释放极快，但那是应用设计问题，不是触发器缺陷

INSERT 场景下也要防负库存？

要。新商品入库、退货补货、系统初始化等操作都走 INSERT，如果插入一条 quantity = -5 的记录，BEFORE UPDATE 触发器完全捕获不到。

正确做法是额外建一个 BEFORE INSERT 触发器，逻辑几乎一样：

IF NEW.quantity <p>别指望靠应用层“只做正数插入”来免责——数据库是最后一道防线，规则必须落在库内。</p>

• INSERT 和 UPDATE 是两个独立事件，触发器必须分别覆盖
• 如果表结构允许 NULL，还得额外判断 NEW.quantity IS NULL，避免空值绕过校验
• 不建议用 AFTER 类型，因为那时数据已写入，只能补救（比如回滚），不如 BEFORE 直接拦截干净

触发器能拦住绝大多数负库存写入，但它不解决“业务逻辑误用”——比如把扣减量当成目标值传进来，或者在非事务上下文中反复重试失败操作。这些得靠应用层配合设计，而不是让数据库替你兜底。