SELECT FOR UPDATE会锁表而非锁行当查询条件未命中主键或唯一索引，导致全表扫描；此时InnoDB退化为表级锁，必须用EXPLAIN确认执行计划type字段非ALL或index。
SELECT FOR UPDATE 什么时候会锁表而不是锁行？
不是加了 FOR UPDATE 就一定安全，它只在查询条件命中主键或唯一索引时才锁单行；否则 InnoDB 会退化为全表扫描+表级锁。比如 WHERE status = 'pending' 没建索引，所有抢购请求都会排队等同一把锁。
- 必须用
EXPLAIN确认执行计划是否走了索引，type 字段不能是ALL或index - 事务里不能混入 HTTP 调用、日志写入、
sleep()等非 DB 操作——锁持有时间从毫秒拉长到秒级，连接池很快耗尽 - 避免在一个事务里多次读取同一行再拼 SQL，可能读到旧值，又漏掉并发更新
UPDATE ... WHERE version = ? AND stock > 0 为什么经常扣成负数？
只写 WHERE version = ? 是无效的，真正起作用的是完整闭环：应用层必须检查 ROW_COUNT() 返回值，为 0 就说明已被别人抢先改过，此时应立即重试或失败，不能静默忽略。
-
stock > 0必须显式写在 WHERE 条件里，否则即使库存为 0，只要 version 匹配，仍会执行SET stock = stock - 1，导致负库存 -
version字段类型只能是INT或BIGINT，禁用TIMESTAMP——毫秒级重复或服务器时钟回拨会导致校验失效 - 重试次数不能硬编码为 3 次就抛错，要结合业务容忍度设计指数退避，否则用户看到“库存不足”只是刚被抢走，而非真没货
ON DUPLICATE KEY UPDATE 能替代库存扣减吗？
它本质是隐式悲观锁，但粒度更细、开销更低：只锁住触发冲突的那条记录（或索引间隙），不锁扫描范围，适合“用户维度幂等下单”这类场景。
- 例如
UNIQUE KEY (user_id, sku_id)，能天然防重复提交，但它不能替代库存扣减的原子性判断 - 如果要先查库存是否充足再下单，仍需
FOR UPDATE或version配合业务逻辑——ON DUPLICATE KEY UPDATE只解决“同一用户重复下单”，不解决“超卖” - 它无法表达 “扣减前 stock >= 1” 这类业务约束，纯靠唯一索引兜底，语义不完整
万级并发下真正扛压的不是锁，而是分层过滤
纯数据库方案到 2000 QPS 左右就逼近瓶颈，必须让 MySQL 只做最终确认，不承担流量过滤职责。
- 前置用
Redis DECR做原子预减，设置过期时间（如 10 分钟），失败直接返回，不打 DB - 预减成功后发 MQ，由消费者执行
UPDATE ... WHERE id = ? AND stock >= ?（注意这里是>=，防止超扣） - 支付成功回调时再查一次 DB 库存，若已售罄则触发退款+补偿通知
- 最关键却最常被跳过的环节是「库存回滚」：预扣成功但用户放弃支付时，必须可靠调用
Redis INCR和 DB 版本号回拨，漏掉这一步，系统会在几小时内不可逆地少卖
