热点行更新让MySQL变慢是因为InnoDB行锁在高并发下导致请求串行排队，尤其秒杀场景中单行锁成为瓶颈；解决方案是虚拟分片拆分压力、Redis预扣减过滤无效请求、降隔离级别减少间隙锁，并避免盲目加锁或冗余索引。
为什么热点行更新会让 MySQL 变慢？
不是锁没起作用，而是它太“称职”了——所有请求都卡在同一个 UPDATE 行上排队。InnoDB 的行锁本意是提升并发，但在秒杀、抢券、余额扣减这类场景下，反而成了串行瓶颈：事务 A 拿着 X 锁没提交，事务 B、C、D 全在等，CPU 扛不住，超时飙升。
- 自增主键 + 聚簇索引 = 物理位置固定，没法靠数据分布摊薄压力
- 哪怕只更新 1 行，
WHERE id = 123命中索引，也拦不住 8000 QPS 全挤在这把锁上 -
REPEATABLE READ隔离级别下还会加临键锁（Next-Key Lock），锁住记录+间隙，进一步扩大等待范围
怎么把“一行热”变成“多行温”？
核心思路是拆——不改业务语义，只把单点压力打散。最直接有效的是虚拟分片（sharding by virtual slots）。
- 原表：
CREATE TABLE goods (id INT PRIMARY KEY, stock INT)→ 单行即热点 - 改后：
CREATE TABLE goods_stock_shard (goods_id INT, shard_id TINYINT, stock INT, PRIMARY KEY(goods_id, shard_id)) - 初始化时把总库存均分到 10 个
shard_id（0~9），扣减时用RAND()或用户 ID 取模随机选一个槽位执行UPDATE - 查总库存用
SUM(stock) FROM goods_stock_shard WHERE goods_id = 123，允许短暂不精确（最终一致性可接受）
这招不依赖中间件，纯 SQL 层改造，上线快、回滚也容易。
应用层该挡在哪一层？
别让数据库当第一道闸口。真实压测里，80% 的无效请求（比如库存已空还狂点）根本没必要进 MySQL。
- 前置用 Redis 做原子预扣：用
DECRBY尝试扣减，返回负数就直接拒绝，不走 DB - 真正要落库的请求，先塞进
Redis Streams或带限速的消费者队列，控制 DB 写入节奏（比如稳定 500 QPS） - 避免在事务里调
HTTP接口或写日志文件——锁会一直挂着，哪怕你只是 sleep(100ms) - 如果业务能容忍幻读，把隔离级别从
REPEATABLE READ改成READ COMMITTED，间隙锁消失，死锁概率断崖下降
哪些“优化”其实更危险？
SQL_NO_CACHE 这类提示词听着很解气，但实际用错就是雪上加霜。
-
SQL_NO_CACHE是禁用查询缓存，而 MySQL 8.0+ 默认已移除查询缓存，用了等于白写，还可能干扰执行计划 - 盲目加
SELECT ... FOR UPDATE前置锁，反而提前占住资源；很多校验逻辑用SELECT ... LOCK IN SHARE MODE或干脆无锁 + 应用层重试更轻量 - 给高频更新字段建太多索引？每多一个二级索引，
UPDATE就得多维护一份 B+ 树，还可能因加锁顺序不一致引发死锁（尤其有多个唯一索引时）
真正的优化不在加什么，而在砍掉什么——砍掉非必要锁、砍掉冗余索引、砍掉事务里的外部依赖。越想靠数据库兜底，系统越脆。
