秒杀更新卡在一行上，是因为innodb聚簇索引使goods_id=123的物理位置固定，所有请求争抢同一行x锁；rr隔离级叠加间隙锁进一步阻塞写入；长事务延长锁持有时间，三者叠加放大冲突。
秒杀场景下 MySQL 行锁竞争卡死，不是并发太高导致的，而是单行热点 + 聚簇索引 + 长事务三者叠加放大了锁冲突；90% 的问题靠拆分热点、缩短事务、改隔离级别就能缓解，不用上分布式锁或分库分表。
为什么秒杀更新会卡在一行上？
InnoDB 行锁本身没错，但秒杀更新通常集中在 goods_id = 123 这样的单行记录上，而 InnoDB 的聚簇索引让这行物理位置固定，所有请求都争抢同一索引页上的 X 锁。更糟的是，默认 REPEATABLE READ 隔离级别会加间隙锁（Gap Lock），哪怕只更新一行，也会锁住前后插入空隙，进一步阻塞新订单写入。
- 自增主键 + 聚簇索引 → 热点行物理位置固化，无法靠数据分布摊薄压力
-
UPDATE stock SET remain = remain - 1 WHERE goods_id = 123 AND remain > 0若goods_id没有索引，会全表扫描并锁住所有行 - 事务里夹了日志打点、MQ 发送、HTTP 回调 → 锁持有时间从几毫秒拉长到几百毫秒
必须用虚拟分片打散单行热点
把“一个商品一个库存字段”改成“一个商品 N 个分片库存”，用哈希或轮询分散写压力，让原本串行的请求变成并行更新多个物理不同行。
- 建表结构：
goods_stock_shard (goods_id, shard_id, stock, version)，联合主键(goods_id, shard_id) - 扣减时随机选一个
shard_id（如shard_id = RAND() * 8 % 8），执行UPDATE ... WHERE goods_id = ? AND shard_id = ? AND stock > 0 - 查总库存需聚合：
SELECT SUM(stock) FROM goods_stock_shard WHERE goods_id = ?，但这个操作不参与秒杀路径，可异步刷新缓存 - 注意：分片数不宜过多（4–16 个足够），否则聚合成本高；也不宜过少（
事务必须压缩到最小粒度
任何非数据库操作都会延长锁持有时间，而秒杀场景下每多 10ms 持锁，排队请求数就指数级增长。
- 禁止在事务内做：
file_put_contents、curl_exec、echo log、发 MQ、调支付接口 - 正确流程：BEGIN → SELECT ... FOR UPDATE WHERE goods_id = ? AND shard_id = ? → 扣减判断 → COMMIT → 再异步通知
- 批量秒杀请求别攒着一起提交，每个请求独立事务；若需防超卖，用
INSERT INTO order_queue (goods_id, user_id) VALUES (?, ?) ON DUPLICATE KEY UPDATE先排队，再由后台消费
隔离级别要切到 READ COMMITTED
REPEATABLE READ 下的间隙锁是秒杀插入阻塞的元凶——新订单插入时发现被 gap lock 拦住，只能等前面事务释放锁。换成 READ COMMITTED 后，InnoDB 只加记录锁，语句执行完就释放不匹配的锁，插入不再被卡。
- 必须确认
binlog_format = 'ROW'（SHOW VARIABLES LIKE 'binlog_format'），否则主从可能不一致 - 全局设置才生效：
SET GLOBAL transaction_isolation = 'READ-COMMITTED'，会话级设置对后续连接无效 - 业务需接受“不可重复读”：同一事务中两次
SELECT可能返回不同库存值，但秒杀场景本就不该依赖多次读取结果 - 即使切到
READ COMMITTED，仍要确保 WHERE 条件走索引，否则照样全表加锁
真正难的不是怎么加锁，而是怎么让锁根本加不到同一行上；虚拟分片和隔离级别切换是见效最快的两步，但最容易被忽略的是：每次上线前必须用 EXPLAIN 看 type 字段，只要出现 ALL 或 index，就说明锁已经失控了。
