秒杀扣库存不能只靠update where stock > 0，因其“读-判-写”三步未原子化，会导致超卖；须用select ... for update配合事务与索引确保行级锁。
为什么秒杀扣库存不能只靠 UPDATE WHERE stock > 0
因为 UPDATE 语句本身不是原子锁，两个并发请求同时读到 stock = 1，都判断通过 WHERE stock > 0，然后各自减 1，结果变成 -1 —— 超卖了。
这不是数据库 bug，是「读-判-写」三步没被锁住。悲观锁要做的，就是把这三步压进一个加锁的读操作里。
-
SELECT ... FOR UPDATE必须在事务中使用，且事务不能自动提交（autocommit=0） - 该语句会锁住查到的行（即使没命中任何行，也可能锁间隙），其他事务对同一行的
SELECT ... FOR UPDATE或UPDATE会被阻塞 - 如果查询条件没走索引，可能升级为表锁，直接拖垮并发能力
怎么写才真正锁住库存行
关键在「锁定粒度」和「索引覆盖」。假设库存存在 products 表里，主键是 id，你要扣的是 product_id = 123 的库存：
- ✅ 正确：
SELECT stock FROM products WHERE id = 123 FOR UPDATE（主键查询，只锁这一行） - ❌ 危险：
SELECT stock FROM products WHERE sku = 'ABC' FOR UPDATE（sku没建索引 → 锁全表） - ❌ 无效：
SELECT stock FROM products WHERE category = 'phone' FOR UPDATE（范围大、无索引 → 行锁变表锁）
执行前务必用 EXPLAIN 看是否走了索引，没走就别上 FOR UPDATE。
事务失败或超时后库存没回滚？
常见现象：用户看到“抢到了”，但最终订单没生成，库存却扣没了。根本原因是事务没正确控制生命周期。
- 应用层必须显式
COMMIT或ROLLBACK，不能依赖连接关闭自动回滚（很多 ORM 默认不关连接） - 设置合理的
innodb_lock_wait_timeout（默认 50 秒），避免一个慢事务卡死整条链路；业务侧应捕获Lock wait timeout exceeded错误，快速失败重试或降级 - 不要在事务里调外部 HTTP 接口——网络延迟可能让锁持有时长失控
悲观锁真比 Redis+Lua 更适合秒杀？
不是更“适合”，而是适用边界不同。悲观锁在 MySQL 里能保证强一致性，但代价是吞吐量硬受限于 InnoDB 行锁性能。
- 单机 MySQL 在锁竞争激烈时，QPS 很容易卡在几百；Redis 可轻松扛几万
EVAL请求 - 如果你的秒杀商品只有 10 个，且要求“绝对不超卖+精确到库位”，那悲观锁够用；如果是百万级流量抢 1 万个商品，得先用 Redis 做前置过滤，再用 MySQL 悲观锁收口最终扣减
- 注意：
SELECT ... FOR UPDATE在读已提交（READ COMMITTED）隔离级别下不会锁间隙，但可重复读（REPEATABLE READ）下会——后者防幻读但更容易死锁
真正难的不是写对那一行 SQL，而是想清楚哪一层做哪一截一致性保障，以及锁住之后，怎么不让它成为整个系统的瓶颈。
