超卖本质是并发读-改-写未串行化导致库存扣减为负，根本原因在于“读旧值→计算→写入”三步脱离锁保护；innodb行锁仅作用于显式加锁语句，普通select不持锁，serializable隔离级别亦无法防护跨事务操作；真正可靠的是单条带条件update（如update goods set stock=stock-1 where id=123 and stock>=1），其天然具备行锁、原子性与无竞态特性。
超卖本质是并发读-改-写没串行化
高并发下商品库存扣减出现负数，不是锁没加，而是加了锁但没拦住“读到旧值→计算新值→写入”这个三步操作的竞态。InnoDB 行锁只锁 UPDATE 或 SELECT ... FOR UPDATE 触发的那行，但若业务代码先 SELECT stock，再判断是否够用，最后才 UPDATE，中间的判断逻辑就脱离了锁保护——两个事务都读到 stock=1，都算出 1−1=0，都成功写入，超卖就发生了。
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。
