MySQL 库存怎么安全扣减？条件 UPDATE、防超卖和受影响行判断

做库存扣减最容易踩坑的反而是不会抛出SQL报错的写法：先查询库存，拿到数值后在业务逻辑里判断是否充足，再发起更新操作。这种场景下两个并发请求很可能同时读到剩余1件库存，之后都完成扣减，直接出现超卖。针对单个SKU的最小粒度扣减逻辑，直接把「库存必须足够」的判断条件写进同一条UPDATE语句，再靠数据库返回的受影响行数决定订单流程能否继续，多数场景下比手动实现应用层读写锁更直接好用。

先搭一个最小库存表

CREATE TABLE inventory (
  sku_id BIGINT PRIMARY KEY,
  available INT NOT NULL,
  updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
    ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB;

InnoDB是MySQL 8.4的默认存储引擎，原生支持事务和行级锁。库存表设计最关键的点是让更新操作通过主键或者高选择性索引精准命中单行；如果走范围更新会大幅扩大锁的覆盖范围，也会拉高不同请求之间的竞争概率。

把校验和扣减合并到同一条UPDATE

UPDATE inventory
SET available = available - 1
WHERE sku_id = 10001
  AND available >= 1;

这条语句不是先读出库存值再在业务层判断后写回，校验条件和写入操作都在数据库侧原子完成。并发请求竞争同一行数据的时候，只有满足条件的更新能真正修改库存值，MySQL官方文档里明确说明，UPDATE会给扫描到的索引记录加锁，所以索引设计的好坏直接决定锁的等待范围有多大。

应用层只靠受影响行数判断最终结果

result, err := updateStock(ctx, db, qty, skuID)
// updateStock 内部运行参数化条件更新：
// UPDATE inventory SET available = available - ?
// WHERE sku_id = ? AND available >= ?
if err != nil { return err }
n, err := result.RowsAffected()
if err != nil { return err }
if n != 1 { return ErrOutOfStock }
return nil

不同语言的数据库驱动的具体返回细节可以参考对应驱动的官方文档，但MySQL本身的规则是UPDATE的受影响行数会返回实际被修改的记录数。这部分的业务约定非常清晰：n == 1 才往下走创建订单的流程，否则直接返回库存不足的提示，同时记录对应的SKU和扣减数量。

什么时候需要用到事务和锁定读

单表扣减的场景下只需要那条带条件的UPDATE就足够。如果后续还要同步生成订单、库存流水、优惠占用记录，就把这些操作放在短事务里，任意一步失败直接回滚。如果必须先读取数据，再基于多行数据的结果做业务决策，可以评估 SELECT ... FOR UPDATE。MySQL官方文档也提示普通的SELECT不会提供足够的并发安全保护，只有锁定读才能阻止其他事务修改对应的行。事务的执行时长越短，出现死锁和等待的概率就越低。

上线检查清单

1. 给 sku_id 建立主键或者唯一索引。
2. 数量校验逻辑放在接口入口层，直接拦截掉零和负数的非法请求。
3. 扣减成功的判断标准严格对齐受影响行数等于1，库存不足的场景做好指标埋点。
4. 多表操作都用短事务处理，捕获到死锁异常后按预设的有限次数重试。
5. 针对同一个SKU做多并发压测，验证不会出现库存为负数的情况。

常见问题

受影响行返回0一定是库存不足吗？

不一定，也可能是对应SKU不存在，或者入参的扣减数量本身不合法。可以在接口层先做参数校验，要不要对外暴露商品是否存在的信息，按照业务本身的安全规则决定就行。

需要先加SELECT FOR UPDATE吗？

单行条件扣减的场景通常不需要。如果涉及跨多行操作，或者必须先读取出数据再做后续计算的场景，再把锁定读放到短事务里处理就好。

出现死锁是不是说明条件UPDATE写错了？

不一定。多个事务以不同的顺序更新多行数据的时候就可能触发死锁，只要统一不同事务更新行的顺序、尽量缩短事务执行时长，同时给应用加上有限次数的重试逻辑就能解决。

能避免库存被扣成负数吗？

条件 available >= qty 是最核心的防护，同时也要在表结构设计和日常监控里及时发现异常的库存数据。

库存扣减的逻辑核心不是靠「我读到库存还有货」来做判断，而是让数据库只有在条件完全符合的时候才修改对应行。靠受影响行数判断结果、用短事务控制多表操作、配套可观测的失败指标，才是这个小接口能扛住高并发场景的核心基础。