在高并发MySQL环境下，如何避免超卖现象？InnoDB行锁与Serializable事务级别如何协同？

本文共计791个文字，预计阅读时间需要4分钟。

在高度并发的情况下，商品库存扣减出现负数的问题，并非是因为锁没有加，而是因为业务代码的逻辑错误。具体来说，操作流程如下：

Serializable 隔离级别不能直接防超卖

SERIALIZABLE 是最高隔离级别，但它对普通 SELECT 会自动加上共享锁（类似 SELECT ... LOCK IN SHARE MODE），对写操作加排他锁，**前提是所有读写都在同一个事务里完成**。如果业务把“查库存”和“扣库存”拆成两个独立事务，或者用了自动提交（autocommit=1），那 SERIALIZABLE 就形同虚设——第一个事务查完就释放锁，第二个事务立刻能读到旧值。

• 必须显式开启事务：BEGIN 或 START TRANSACTION
• 查库存必须带锁：SELECT stock FROM goods WHERE id = 123 FOR UPDATE（不能只用普通 SELECT）
• 扣减和更新必须在同一个事务内完成，且不能中途 COMMIT
• 客户端连接不能处于 autocommit=1 状态，否则每条语句自成事务

真正可靠的写法：一条带条件的 UPDATE

比依赖事务隔离级别更稳的方式，是把“检查 + 更新”压进一条原子 SQL：

UPDATE goods SET stock = stock - 1 WHERE id = 123 AND stock >= 1;

这条语句执行后，检查 ROW_COUNT()（MySQL 客户端可获取）：

• 返回 1 → 扣减成功
• 返回 0 → 库存不足或记录不存在，没做任何修改

它天然具备：行锁（InnoDB 自动对匹配的行加 X 锁）、原子性（WHERE 和 SET 同时生效）、无竞态（不依赖应用层读取后再判断）。即使并发 1000 个请求，也只会有一个拿到锁并满足 stock >= 1 条件，其余全部失败，不会超卖。

行锁失效的典型坑

以为加了 FOR UPDATE 就万事大吉，结果还是超卖，往往因为锁根本没加上：

• 查询条件没走索引：比如 WHERE status = 1 但 status 列无索引 → InnoDB 升级为表锁或锁住所有行，性能崩，还可能因死锁被回滚
• 使用了非唯一条件查多行：如 SELECT ... FOR UPDATE WHERE category_id = 5 → 锁住所有匹配行，若并发高且范围大，容易锁冲突
• 事务中混用不同索引字段：先 SELECT ... FOR UPDATE WHERE id = 123，再 UPDATE ... WHERE sku_code = 'abc' → 第二条 UPDATE 可能锁另一行，或触发间隙锁问题
• WHERE 中用了函数或表达式：WHERE ABS(id) = 123 → 无法使用索引，行锁失效

最稳妥的起点永远是：主键或唯一索引 + 单行操作 + 一条带条件 UPDATE。