行锁在热点更新时成性能瓶颈，因多事务争抢同一行X锁导致排队等待；聚簇索引使物理位置固定，无法分散压力；锁持有时间长引发等待雪崩。
为什么“行锁”在热点更新时反而成了性能瓶颈
很多人默认 InnoDB 行锁粒度小就等于高并发友好，但真实场景中，当大量请求集中更新同一行（比如商品 id=123 的库存），所有事务都在抢同一个 X 锁——不是并行，是排队。更糟的是，InnoDB 的聚簇索引让这行物理位置固定，没法靠数据分布分散压力；事务提交慢 → 锁持有时间长 → 等待队列雪崩。
- 典型现象：
SHOW ENGINE INNODB STATUS里反复看到waiting for trx id，CPU 扛到 95%+，但磁盘和网络其实很闲 - 别被“行锁”二字迷惑：它不解决争用，只解决冲突；争用本身得靠设计绕开
- 自增主键 + 单行库存 = 天然热点放大器，不是 bug，是结构使然
用 Redis 分片 + 原子预扣减，把数据库从第一线撤下来
核心思路：不让 MySQL 承担“判断+扣减”的实时一致性压力，而是用 Redis 做轻量校验和限流，MySQL 只做最终落库。
- 先在 Redis 中为商品建
goods:123:stock，初始值设为总库存（如 1000） - 用户抢购时，用
DECRBY goods:123:stock 1原子操作；返回值 ≥ 0 才放行，否则直接拒绝 - 后台消费者从队列（如
Redis Streams）按可控速率（如 500 QPS）批量写入 MySQL，执行UPDATE goods SET stock = stock - ? WHERE id = 123 AND stock >= ? - 关键点：Redis 分片可选，比如按
goods_id % 10拆成 10 个 key，进一步分散单 key 压力
MySQL 层必须做的三件事：索引、隔离级、事务边界
哪怕用了缓存，只要还走 MySQL 写入，这些底层约束就逃不掉。漏掉任意一条，都可能让优化前功尽弃。
- WHERE 条件必须命中**最左匹配的唯一索引**，否则
UPDATE可能升级为全表扫描+锁表；用EXPLAIN看key和rows是硬指标 - 把隔离级别从默认的
REPEATABLE READ改为READ COMMITTED：它不加间隙锁，死锁概率骤降，且多数业务根本不需要可重复读语义 - 事务只包
UPDATE一行 + 检查ROW_COUNT()，绝不在里面调 HTTP、解析 JSON、或sleep(1)—— 长事务是锁滞留头号元凶
别迷信“乐观锁”，强一致场景下它只是转移了战场
用 version 字段或 CAS 更新（如 UPDATE t SET status=2, version=version+1 WHERE id=123 AND version=5）确实能减少 DB 锁，但它把重试逻辑甩给了应用层。一旦并发超高，重试风暴会压垮服务本身。
- 适合场景：状态位切换、非核心计数器；不适合：秒杀库存、资金余额等强一致+高频写
- 如果真要用，务必限制重试次数（如 ≤ 3 次）+ 加退避（如
Thread.sleep(10)），否则 CPU 全耗在空转上 - 更稳妥的做法是：Redis 预扣减 + MySQL 异步落库 + 对账补偿，而不是在 DB 层硬刚乐观锁
真正难的不是写对一行 SQL，而是确认“这一行要不要进数据库”。很多团队卡在“必须强一致”的执念里，结果把 MySQL 当成分布式协调器来用。其实多数业务能接受几秒延迟，只要不超卖、不错账——把一致性边界划清楚，比调参重要得多。
