热点行问题本质是多事务争抢同一行锁导致性能下降，解决核心是打散写压力：分桶拆分、应用层预分流、乐观锁+版本控制、写入分离与专用通道。
热点行问题本质是多个事务争抢同一行数据的锁，导致吞吐骤降、响应延迟甚至超时。解决核心不是“避开它”，而是把集中压力打散——让写操作从单点变成多点。
分桶拆分：把一行变多行
这是最直接有效的手段。不修改业务语义，只改变存储结构：
- 原表：
CREATE TABLE products (id INT PRIMARY KEY, stock INT); - 改造后：
CREATE TABLE product_stock (product_id INT, bucket_id TINYINT, stock INT, PRIMARY KEY(product_id, bucket_id)); - 初始化时将总库存均分到10个桶（
bucket_id0–9），扣减时随机或轮询选一个桶执行UPDATE ... SET stock = stock - 1 WHERE product_id = ? AND bucket_id = ? - 查总数用
SUM(stock)聚合，写压力自然分散为原来的约1/10
应用层预分流：在到达数据库前就做减法
避免所有请求都涌向DB，用轻量级组件提前拦截和调度：
- 用 Redis List 或 Streams 做分布式队列，用户点击“抢购”后仅入队，不立刻更新DB
- 后台消费者以可控速率（如每秒500笔）拉取并批量处理，同时用
DECRBY做原子校验，快速拒绝超卖 - 配合本地缓存（如 Caffeine）缓存商品基础信息，减少对DB的查询依赖
乐观锁 + 版本控制：减少锁持有时间
适合更新频次高但冲突概率不极端的场景：
- 在表中增加
version字段，每次更新带上WHERE version = ? - 更新成功则
version自增；失败说明被其他事务抢先修改，可重试或降级提示 - 相比行锁，它把“等待锁”变成“检查+重试”，大幅缩短事务持有资源的时间
写入分离与专用通道
对极敏感的热点数据，可考虑架构层面隔离：
- 单独部署高性能写库（如基于 SSD 的 MySQL 实例），只承载库存、计数器等高频更新
- 读请求走主从复制后的从库，或通过缓存兜底
- 必要时引入轻量消息队列（如 Pulsar/Kafka），将强一致性要求放宽至最终一致（如播放量、点赞数）
