用 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
，结果扣出负数还自以为安全。这两个点线上一出问题，就是资损。
