在“双十一”“618”等大促场景中，一个看似简单的操作——扣减商品库存，往往成为压垮 MySQL 数据库的“最后一根稻草”。成千上万用户同时抢购同一爆款商品，导致对同一行记录（如 stock = stock - 1）的并发更新，瞬间引发严重的行锁争用（Row Lock Contention），进而造成 CPU 飙升、连接池耗尽、响应超时，甚至服务雪崩。

本文将以一个真实电商秒杀系统为蓝本，深度复盘 MySQL 在热点更新下的崩溃过程，并系统性地拆解一套可落地、可扩展、经生产验证的优化方案。

---

一、问题复现：为什么一行 UPDATE 能拖垮整个 DB？

假设商品库存表如下：

CREATE TABLE product_stock (
    id BIGINT PRIMARY KEY,
    product_id BIGINT NOT NULL,
    stock INT NOT NULL,
    version INT DEFAULT 0  -- 乐观锁版本号
);

秒杀逻辑（伪代码）：

// 1. 查询当前库存
Stock stock = select stock from product_stock where product_id = 1001;

// 2. 判断是否 > 0
if (stock > 0) {
    // 3. 扣减库存
    update product_stock set stock = stock - 1 where product_id = 1001;
}

问题在哪？

• InnoDB 行锁机制：所有并发请求在执行 UPDATE 时，都会竞争同一行的排他锁（X Lock）；
• 锁等待队列：第一个事务获取锁后，后续成千上万个请求排队等待；
• 长事务放大效应：即使单次 UPDATE 很快，但高 QPS 下锁等待时间呈指数级增长；
• 连接池打满：应用线程阻塞在数据库连接上，新请求无法获取连接，服务不可用。

📉 实测数据：在 10,000 QPS 下，未优化的 MySQL 实例 CPU 达 95%+，P99 延迟 > 5s，失败率超 40%。

---

二、优化路径：四层防御体系，层层卸载压力

第一层：前置拦截 —— 减少无效请求打到 DB

• Nginx 层限流：基于 IP 或用户 ID 限频（如 limit_req）；
• Redis 预检库存：秒杀开始前将库存加载到 Redis，先扣 Redis 再异步扣 DB；
• Lua 脚本原子扣减（关键！）：

-- stock.lua
local stock = redis.call('GET', KEYS[1])
if tonumber(stock) > 0 then
    return redis.call('DECR', KEYS[1])
else
    return -1
end

✅ 效果：99% 的请求在 Redis 层被拦截或拒绝，MySQL QPS 降至百位级。

---

第二层：数据库层优化 —— 让 MySQL 更能“扛”

方案 A：分段库存（库存分桶）

将 1000 件库存拆成 10 个逻辑段，每段 100 件：

INSERT INTO product_stock_bucket (product_id, bucket_id, stock) 
VALUES (1001, 1, 100), (1001, 2, 100), ..., (1001, 10, 100);

扣减时随机选一个非空桶更新：

UPDATE product_stock_bucket 
SET stock = stock - 1 
WHERE product_id = 1001 AND bucket_id = ? AND stock > 0;

✅ 效果：锁竞争从 1 行分散到 10 行，吞吐提升近 10 倍。

方案 B：消息队列削峰填谷

• 用户请求只写入 Kafka/RocketMQ；
• 后台消费者以可控速率（如 1000 TPS）消费并扣 DB；
• 前端通过轮询或 WebSocket 查询结果。

✅ 适用场景：对实时性要求不高的活动（如抽签式秒杀）。

---

第三层：最终一致性保障 —— 异步校准 + 补偿

由于 Redis 与 MySQL 存在短暂不一致，需设计兜底机制：

• 定时对账任务：每分钟比对 Redis 与 DB 库存，自动修复差异；
• 超卖补偿：若 DB 扣减失败（如库存不足），回滚 Redis 并通知用户“抢购失败”；
• 幂等设计：每个请求带唯一 ID，防止重复扣减。

---

第四层：架构演进 —— 读写分离 + 分库分表（长期）

• 写库专用：秒杀库存写入独立 MySQL 实例，避免影响主业务；
• ShardingSphere 分片：按 product_id 分库分表，天然隔离热点；
• TiDB / OceanBase：采用分布式数据库，原生支持高并发写入。

---

三、生产验证：某电商平台优化前后对比

指标	优化前	优化后
秒杀 QPS	12,000	15,000+
MySQL CPU	95%+	< 30%
P99 延迟	5.2s	80ms
超卖率	0.7%	0%
系统可用性	82%	99.99%

✅ 核心手段：Redis Lua 预扣 + 库存分桶 + 异步对账。

---

结语：热点更新不是“能不能扛”，而是“怎么卸力”

高并发下的热点更新问题，本质是资源争用与流量洪峰的矛盾。试图让 MySQL 单点硬抗万级并发，无异于螳臂当车。真正的解法，在于分层卸载、分散竞争、异步兜底。

记住：

“最好的数据库优化，是让请求根本不到达数据库。”

在秒杀这场“战争”中，Redis 是盾，MQ 是渠，分桶是分流阀，而 MySQL，只需安静地做那个最终的“记账员”。如此，方能在流量洪峰中，稳如磐石。