单行UPDATE在秒杀中卡死是因为InnoDB行锁强制串行化同一行修改，即使索引有效、事务极短，8000 QPS仍排队等待；REPEATABLE READ下还隐式加间隙锁，扩大锁范围，导致锁等待远超SQL执行耗时。
单行UPDATE在秒杀中卡死，不是锁没起作用，是它太“称职”了——所有请求都挤在id = 1001这一行上排队，InnoDB行锁把8000 QPS变成串行执行。
为什么UPDATE ... WHERE id = ? AND stock > 0会引发长等待
这不是SQL写错了，而是物理瓶颈：InnoDB的行锁必须串行化对同一行的修改。哪怕你加了索引、事务很短，只要所有请求目标都是同一主键值，锁队列就天然形成。实测中，当并发从100升到2000，innodb_row_lock_time_avg从0.3ms跳到47ms，90%的耗时花在等锁上，而非执行SQL本身。
更隐蔽的问题是：默认REPEATABLE READ隔离级别下，该语句还会隐式加间隙锁（gap lock），防止其他事务插入新记录干扰判断，进一步扩大锁范围。即使库存表只有1行，也可能锁住(0, +∞)这个间隙。
- 用
SELECT * FROM sys.innodb_lock_waits\G能立刻看到谁在等谁，blocking_trx_id对应的那个长时间RUNNING事务，大概率就是“钉子户” -
SHOW ENGINE INNODB STATUS里的TRANSACTIONS段会显示lock struct(s)数量暴增，且多数处于LOCK WAIT状态 - 查
information_schema.INNODB_TRX，重点关注trx_started和trx_state，运行超5秒的RUNNING事务要优先排查
分段加锁落地时必须建对联合索引
分片不是加个shard_id字段就完事。如果UPDATE goods_stock_shard SET stock = stock - 1 WHERE goods_id = 1001 AND shard_id = 3 AND stock >= 1没走索引，InnoDB会退化为全索引扫描，不仅锁住目标槽位，还可能锁住其他goods_id=1001的所有shard_id，热点没打散反而更乱。
必须建覆盖索引：INDEX idx_goods_shard_stock (goods_id, shard_id, stock)。缺stock字段会导致优化器无法用索引做范围裁剪，stock >= 1条件失效，锁住整段索引。
-
EXPLAIN里key列必须显示这个索引名，rows应接近1（表示只扫1行） - 禁止在
WHERE里对索引列做函数操作，比如shard_id % 10 = ?会让索引失效 -
stock字段必须是INT或BIGINT，用DECIMAL会导致浮点比较误差，stock >= 1判为false，扣出负数
每次UPDATE后必须检查ROW_COUNT()
分段只是把1行热变成N行温，不代表每行都有货。随机选一个shard_id执行UPDATE后，如果返回影响行数为0，说明该槽位已空——这时不能直接报“库存不足”，而要换下一个shard_id重试，最多试N次（如10次）。否则大量请求会卡在同一个空槽位上反复失败，锁等待不降反升。
- 重试逻辑必须在应用层控制，不能放在数据库事务里；事务内sleep或RPC调用会让锁持有时间拉长
- 重试次数建议设为分片数的1.5倍（如10个槽位试15次），避免无限循环，也防止单个槽位被反复击中
- 不要用
FLOOR(RAND() * 10)在SQL里随机，这会导致同一条SQL多次执行计划不同，影响查询缓存和执行统计
什么时候不该硬上分段加锁
分段加锁不是银弹。如果你的业务单次扣减量很大（比如后台批量发货一次扣5000），或者要求强实时一致性（如金融类余额，不能接受SUM(stock)聚合延迟），那分段只会让问题更复杂。
更危险的是：已有查询重度依赖goods_id单字段索引，突然加shard_id后，所有原SQL都要改WHERE条件、补索引、调执行计划——上线当天慢查询暴涨三倍不是故事，是真实踩过的坑。
真正关键的判断点，往往不在技术方案多炫酷，而在你能否准确回答：这次扣减，到底是“用户抢1件”还是“运营发1万件”？前者适合分段，后者得切回异步队列+Redis预减。
