普通UPDATE易超卖是因为“读-判-写”非原子：两请求同时读到stock=1，均执行减1致库存-1；WHERE stock>0为快照读不加锁，无法阻塞并发修改。
为什么普通 UPDATE 容易导致超卖
电商下单时，如果只用 UPDATE product SET stock = stock - 1 WHERE id = 123 AND stock > 0，看似加了库存判断，但并发高时仍会超卖。根本原因是：读取库存和更新库存不是原子操作，两个请求可能同时读到 stock=1，然后都执行减 1，最终变成 -1。
- MySQL 默认隔离级别是
REPEATABLE READ，它不能阻止这种“读-改-写”竞态 -
WHERE stock > 0是快照读，不加锁，无法阻塞其他事务的并发修改 - 单条 UPDATE 在满足条件时才执行，但判断和执行之间存在时间窗口
用 SELECT ... FOR UPDATE 显式加锁
在事务里先查库存再扣减，必须让查询带上行锁，确保同一行不会被多个事务同时修改：
START TRANSACTION; SELECT stock FROM product WHERE id = 123 LOCK IN SHARE MODE; -- ❌ 错误：共享锁不阻止其他事务 UPDATE SELECT stock FROM product WHERE id = 123 FOR UPDATE; -- ✅ 正确：排他锁，阻塞其他事务对这行的读写 -- 检查 stock >= 1，再执行 UPDATE UPDATE product SET stock = stock - 1 WHERE id = 123; COMMIT;
-
FOR UPDATE必须在事务内使用，且 WHERE 条件要走索引（比如主键或唯一索引），否则会升级为表锁 - 如果 WHERE 不走索引，MySQL 可能锁住整个聚簇索引，严重拖慢并发
- 不要依赖应用层判断后才执行 UPDATE；必须在锁住行之后、UPDATE 之前做判断，否则锁就白加了
更安全的单 SQL 原子扣减方案
避免应用层判断，把库存校验和扣减合并到一条语句，靠数据库保证原子性：
UPDATE product SET stock = stock - 1 WHERE id = 123 AND stock >= 1;
- 执行后检查
ROW_COUNT()：等于 1 表示扣减成功；0 表示库存不足或已被扣完 - 这条语句本身具备原子性，不需要额外事务包裹（但建议仍包在事务里，方便后续插入订单等操作）
- 注意：
stock >= 1是当前读，会触发隐式加锁（InnoDB 的 next-key lock），效果接近FOR UPDATE，但更轻量 - 别写成
stock > 0，整数库存最小值是 0，> 0会让 stock=0 时无法匹配，但语义上 stock=0 就该拒绝扣减，所以>= 1更准确
事务失败后如何重试与幂等
即使加了锁或原子更新，网络抖动、死锁、连接中断仍会导致事务失败，必须设计重试逻辑：
- 捕获 MySQL 错误码：
1213（Deadlock）、2006（MySQL server has gone away）、2013（Lost connection）需重试 - 重试前加随机小延迟（如 10–100ms），避免雪崩式重试
- 订单号必须全局唯一，且插入订单表时用
INSERT ... ON DUPLICATE KEY UPDATE或唯一索引约束，防止重复下单 - 不要依赖“查订单是否存在”再决定是否创建——查+插非原子，应直接插，靠唯一键拦截
真正难的不是写对那条 UPDATE，而是确认锁的范围、理解 FOR UPDATE 和 UPDATE ... WHERE 在不同索引下的行为差异，以及在分布式环境下怎么跟 Redis 库存预减协同。这些细节一错，压测时才暴露。
