为什么直接 UPDATE 库存会超卖
在并发请求下，多个事务同时读取同一行库存值（比如 10），各自减 1 后写回，最终可能只扣了 1 次，变成 9 而不是预期的 8。本质是「读-改-写」非原子操作，中间被其他事务插队。
典型错误写法：
SELECT stock FROM goods WHERE id = 1→ 应用层计算
new_stock = old_stock - 1→
UPDATE goods SET stock = new_stock WHERE id = 1。这组操作没有锁住读取到写入之间的窗口。 即使加了
SELECT ... FOR UPDATE，若没在事务内、或没正确开启事务（如 autocommit=1），锁会立刻释放 WHERE 条件未命中索引时，
FOR UPDATE可能升级为表锁，拖垮性能 应用层做判断（如
if (stock > 0)）再更新，判断和更新之间仍有竞态
用 UPDATE ... WHERE 原子扣减 + 影响行数校验
把「判断是否足够」和「扣减」合并进一条 SQL，由 MySQL 保证原子性。执行后检查
affected_rows是否为 1，为 0 表示库存不足或记录不存在。
示例（InnoDB，goods 表主键为 id，stock 为 INT）：
BEGIN; UPDATE goods SET stock = stock - 1 WHERE id = 1 AND stock >= 1; -- 应用层检查上一条 UPDATE 的影响行数 -- 若为 0：抛异常或返回“库存不足” COMMIT;
AND stock >= 1是关键，它让 UPDATE 自带业务条件，失败不修改数据 必须搭配事务，否则无法回滚；且建议显式
BEGIN/
COMMIT，避免依赖 autocommit 配置 该语句会为满足条件的行加行级 X 锁，其他并发 UPDATE 会被阻塞直到前一个事务结束
乐观锁方案：version 字段 + CAS 更新
适合读多写少、冲突概率低的场景。不依赖数据库锁，靠应用层重试降低阻塞。
goods 表增加
versionINT 字段（初始为 0），每次更新都校验并递增：
UPDATE goods SET stock = stock - 1, version = version + 1 WHERE id = 1 AND stock >= 1 AND version = 5;应用先
SELECT id, stock, version FROM goods WHERE id = 1，拿到当前 version（比如 5） 拼装 UPDATE 语句时带上
version = 5，确保没被别人改过 若
affected_rows == 0，说明 version 已变，需重新 SELECT → 计算 → 重试（建议限制重试次数，如 3 次） 注意：version 冲突时不能简单 sleep 后重试，要重新查最新 stock，否则可能用过期值继续扣
高并发下的实际取舍点
真实系统里没有银弹。悲观锁（
FOR UPDATE或 WHERE 扣减）吞吐受限于数据库行锁排队；乐观锁在秒杀场景下重试风暴可能打崩应用。 秒杀类极端场景：建议前置 Redis 计数器预减（Lua 原子），成功后再走 MySQL 扣减，失败则快速返回 普通电商下单：优先用
UPDATE ... WHERE stock >= N，简单可靠，配合合理索引和连接池即可扛住数千 QPS 务必给
goods.id加主键索引，WHERE 中的
stock条件若频繁使用，可考虑联合索引
(id, stock)加速范围判断 别忽略事务隔离级别：
READ COMMITTED足够，
REPEATABLE READ下间隙锁可能引发死锁，尤其 WHERE 条件未命中时
