大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
上周讲了MySQL参数调优，有读者问：“参数都调了，但秒杀的时候一条UPDATE库存的SQL还是卡得要死，怎么办？”
这个问题问到点子上了。参数调优能解决的是“数据库跑得不够快”的问题，但秒杀场景的瓶颈往往不在参数，在行锁。
成千上万个请求同时抢同一行库存数据，就像几十个人挤一扇门——门一次只能过一个人，后面的人全在排队。这种场景下，哪怕你的数据库参数调得再好，行锁本身也成了天花板。
今天把这个场景拆开讲一遍：一条UPDATE语句在秒杀时到底发生了什么、为什么会卡住、以及怎么让它快起来。
一、问题还原：一行UPDATE是怎么拖垮整个数据库的
假设有一个秒杀系统，商品ID=1001，库存100件。扣库存的SQL长这样：
sql
UPDATE inventory SET stock = stock - 1 WHERE product_id = 1001 AND stock > 0;
5000个并发请求同时执行这条SQL。你以为数据库会并行处理？不会。同一时刻只能有一个事务持有这行的行锁，其他4999个请求全部在排队等锁释放。
排队本身就有代价：
锁等待超时：默认
innodb_lock_wait_timeout=50秒，等不到就报错死锁检测消耗CPU：InnoDB要不断检查这些等待会不会形成死锁，大量并发时死锁检测本身就能把CPU吃满
连接池耗尽：大量连接卡在“等锁”状态，新请求进不来
一句UPDATE就能把整个DB拖垮，不是危言耸听。
二、为什么分库分表救不了热点行？
有人会说：“把库存拆分到多个分片不就行了吗？”
库存拆分确实能解决一部分问题，但效果有限。把商品库存拆成10个分片，每个分片承担1/10的流量——扣减逻辑变成了“先找有库存的分片再扣”，引入了额外的路由逻辑和跨分片协调开销。
分库分表解决的是“总量太大”的问题，不是“单行太热”的问题。热点行永远只有一个——商品ID=1001这行数据。拆了表，这行数据还在某个分片里，锁竞争依然存在。
真正要解决的，是“怎么让同一行数据被多个请求同时访问时，系统还能扛得住”。
三、数据库层的优化方案
方案一：热点更新排队机制
云厂商的MySQL分支（如腾讯云TXSQL、阿里云PolarDB）提供了热点更新排队功能。核心思路是：事务在加锁前先判断是否为热点行，如果是则进入等待队列，前一个事务提交后才唤醒下一个。
效果：把随机争抢变成有序排队，减少死锁检测开销。实测可提升1.5-10倍吞吐量。
代价：需要特定版本支持（MySQL 5.7 20250330+或8.0 20241001+），且仅支持主键和唯一键的热点行。
方案二：Inventory Hint（阿里内核补丁）
阿里自研的内核补丁，通过特殊的hint语法优化热点行并发更新。
核心思想是让热点更新“排队”而不是“打架”：
减少行级锁等待：智能排队机制
减少B+树遍历：Row Cache缓存优化
效果：结合Inventory Hint，单行热点更新性能可提升5倍以上。
四、业务层的优化策略
策略一：库存拆分（分散锁压力）
把100件库存拆成10个库存分片（stock_1到stock_10），每个分片10件。扣减时随机选一个分片扣。
优点：实现相对简单，适合中小规模场景。锁粒度降低，并发能力提升。
缺点：需要处理分片库存不均的问题——某个分片扣完了，其他分片还有库存，路由逻辑变复杂。
策略二：Redis预扣减 + 异步落库
秒杀流量先打到Redis，在Redis中完成库存预扣减，真正成功下单后再异步写入MySQL。
流程：请求→Redis扣库存（原子操作）→返回成功→异步写入MySQL落库
优点：MySQL的写入压力从每秒数万降到每秒数百
缺点：需要处理Redis和MySQL的数据一致性（最终一致性方案）
策略三：请求合并（组提交）
将同一热点行的多个更新请求在应用层合并成一次批量更新。比如100个请求要各扣1件库存，合并成一条UPDATE inventory SET stock = stock - 100 WHERE product_id = 1001 AND stock >= 100。
优点：100次行锁变成1次
缺点：需要业务允许批量扣减，且要处理“部分成功”的复杂逻辑。
五、一个真实的优化案例
某电商平台秒杀场景，单商品库存扣减的TPS峰值约2000，MySQL的CPU使用率长期在85%以上，偶尔冲到100%导致服务超时。
优化前：单条UPDATE直接怼数据库，500并发下平均响应时间约500ms，P99超过2秒。
优化路径：
第一步：启用热点更新排队机制。相同配置下TPS从2000提升到3500，CPU从85%降到60%。
第二步：引入Redis预扣减。MySQL的写入压力从每秒3500降到每秒约500，CPU降到30%以下。
第三步：库存拆分。将热点商品的库存拆成5个逻辑分片，进一步降低单行锁竞争。
优化后：500并发下平均响应时间降到5ms，P99控制在20ms以内。系统扛住了10倍于之前的流量。
六、总结
热点行更新是秒杀场景下的“头号杀手”，但它的本质问题很简单——行锁是串行的，高并发下必然成为瓶颈。
优化路径的优先级：
| 优先级 | 方案 | 适用场景 | 实施成本 |
|---|---|---|---|
| 1 | Redis预扣减 + 异步落库 | 所有秒杀场景 | 中等 |
| 2 | 热点更新排队机制 | 云数据库环境 | 低（开启参数即可） |
| 3 | 库存拆分 | 中小规模 | 低 |
| 4 | 请求合并/组提交 | 批量扣减场景 | 中等 |
| 5 | Inventory Hint | 阿里系数据库 | 低（需内核支持） |
核心思路就一句话：让热点数据“绕开”数据库，或者让数据库“排队”处理热点请求。直接硬扛行锁，再好的硬件也扛不住。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~