根本原因是热点行物理位置固化与锁争用叠加：单行更新在聚簇索引下始终落在同一数据页，引发页级latch、redo/binlog等底层资源串行化竞争，即使命中索引且隔离级别为rc，x锁本身仍强制1000并发请求排队等待同一行。
MySQL在高并发更新单行数据时出现热点瓶颈，根本原因不是“锁太重”，而是所有请求被迫挤在同一个物理位置、同一把X锁、同一个事务提交路径上——InnoDB的强一致性机制在此场景下反而成了串行化放大器。
为什么WHERE条件命中单行，还是锁住整个写链路？
InnoDB行锁只在满足特定前提时才真正“按行”生效。一旦出现以下任一情况，单行UPDATE就会退化为事实上的串行执行：
-
WHERE条件未命中索引或走错索引：比如product_id = 123字段没建索引，触发全表扫描，每条记录都加X锁 - 隔离级别是
REPEATABLE READ：会自动加上间隙锁（Gap Lock），哪怕只更新一行，也可能锁住(122, 124)范围，阻塞相邻product_id的插入或更新 - 事务中混入其他操作：比如UPDATE后又调用HTTP接口、写日志、执行SLEEP，导致锁持有时间从毫秒级拉长到秒级，排队雪球越滚越大
聚簇索引让“热点”彻底固化
MySQL默认用主键构建聚簇索引，数据行物理存储顺序和主键逻辑顺序一致。当所有请求都更新product_id = 123这一行时：
- 该行始终落在同一个数据页（Page）里
- 缓冲池（Buffer Pool）中对应页的latch（页级锁）被高频争抢
- redo log写入、binlog刷盘、flush list管理等后台动作也被迫同步等待这一页的修改完成
换句话说，你试图压测的是“业务逻辑并发度”，但MySQL底层真正卡住的是“单个数据页的物理IO与内存访问路径”。
READ COMMITTED能缓解，但不解决本质问题
切到READ COMMITTED确实能禁用间隙锁，减少误锁范围，也降低死锁概率。但它无法消除X锁本身的竞争：
- 1000个并发UPDATE仍要排队获取同一行的X锁
- 锁等待队列（lock wait queue）长度直接决定P99延迟——实测中，队列超50就明显抖动，超200基本超时
- 连接池若未设合理timeout，会快速耗尽，引发级联失败
所以只调隔离级别，就像给堵死的高速公路换限速牌——标识变了，但车还是过不去。
应用层不做分流，数据库层再怎么调参都是徒劳
很多团队花大量时间调innodb_thread_concurrency、innodb_lock_wait_timeout甚至升级SSD，但只要应用还把所有扣减请求原样发向UPDATE goods SET stock = stock - 1 WHERE product_id = 123，瓶颈就永远在那一行。
真正有效的解法必须跨层协同：Redis前置校验拦截无效请求、消息队列削峰、分片更新分散物理压力、云厂商热点排队功能兜底——单点优化只能延缓崩溃，不能改变锁争用的数学本质。
