库存超卖本质是并发事务读取旧值后扣减，解法包括：①SELECT...FOR UPDATE加行锁（需id为主键/唯一索引）；②UPDATE...WHERE原子更新（WHERE含stock>=1）；③Redis+Lua预减库存（注意最终一致性与降级）。
用 SELECT ... FOR UPDATE 在事务中锁定库存行
超卖本质是多个事务同时读到旧库存值，各自减一后写回。最直接的解法是在更新前加行级写锁，让后续事务排队等待。
关键前提是：id 字段必须是主键或唯一索引，否则 SELECT ... FOR UPDATE 可能锁表或锁范围，性能崩塌。
- 必须在
BEGIN和COMMIT之间执行，否则锁不生效 - 避免在锁住库存后做耗时操作（如调用外部 API、发邮件），否则锁持有时间过长，拖垮并发能力
- 如果库存字段在
WHERE条件里（比如WHERE stock > 0），MySQL 无法精确锁定，可能漏锁或扩大锁定范围
BEGIN; SELECT stock FROM products WHERE id = 123 FOR UPDATE; -- 检查 stock 是否足够 UPDATE products SET stock = stock - 1 WHERE id = 123 AND stock >= 1; -- 注意：UPDATE 必须带 stock >= 1 条件，防止幻读导致扣成负数 COMMIT;
用 UPDATE ... WHERE 原子判断+更新，跳过事务开销
当业务逻辑简单（只扣库存、不依赖中间计算），可绕过显式事务和锁，靠 UPDATE 语句自身原子性兜底。
MySQL 的 UPDATE 是原子操作，WHERE 条件与赋值同时生效，不会出现“先查再判再更”的竞态窗口。
-
UPDATE返回影响行数，为 0 表示库存不足或记录不存在，应用层据此返回失败 - 务必把库存校验写进
WHERE子句，例如WHERE stock >= 1，不能只靠应用层 if 判断 - 该方式不阻塞其他读请求（
SELECT不被锁），吞吐更高，但无法支撑“扣库存 + 写订单 + 记日志”这类多步强一致性场景
UPDATE products SET stock = stock - 1 WHERE id = 123 AND stock >= 1;
Redis + Lua 做前置库存预减，缓解 MySQL 压力
高并发秒杀场景下，MySQL 直接扛写压力容易被打挂。常用做法是把库存放到 Redis，用 EVAL 执行 Lua 脚本保证原子性预减，成功后再异步落库。
注意：这引入了最终一致性，下单成功 ≠ 库存已扣减到 MySQL，需配套补偿机制（如超时未支付自动回滚 Redis + MySQL）。
- Lua 脚本必须用
redis.call('decr')或redis.call('hincrby')，不能用GET + SET拆开，否则失去原子性 - Redis 库存初始值要和 MySQL 一致，上线前需全量同步，且需监听 MySQL binlog 做双向对账
- 若 Redis 宕机，需降级到 MySQL 方案（如通过数据库连接池限流 +
UPDATE ... WHERE），不能直接报错
-- 示例 Lua 脚本（传入 key 和扣减量）
if redis.call("get", KEYS[1]) >= ARGV[1] then
return redis.call("decrby", KEYS[1], ARGV[1])
else
return -1
end
为什么乐观锁（version 字段）在这里不推荐
乐观锁适合冲突概率低、更新频率低的场景（如用户资料修改）。库存扣减是高频、高冲突操作，UPDATE ... WHERE version = ? 失败重试会引发大量无意义循环和数据库压力。
- 每次失败都要重新查最新
stock和version，网络+SQL 开销翻倍 - 重试逻辑若没加退避（如指数退避），可能瞬间打爆数据库连接池
- 无法防止“查到有库存 → 但另一事务已扣完 → 当前事务仍尝试扣”的问题，除非把库存校验也塞进
WHERE，那就退化成上面的原子UPDATE方案了
实际中最容易被忽略的是：库存字段没加索引却用了 FOR UPDATE，导致锁表；或者 UPDATE 语句漏写了 AND stock >= 1，结果扣出负数还自以为安全。这两个点线上一出问题，就是资损。
