行锁优化关键是“怎么锁得更准、更轻、更短”：精准锁定避免锁升级，分桶拆分分散热点，应用层预分流削峰填谷，乐观锁减少阻塞。
行锁粒度控制不是“加不加锁”的选择题，而是“怎么锁得更准、更轻、更短”的实操问题。热点行之所以拖垮性能，核心在于大量事务反复争抢同一行的锁资源。缓解的关键，是让写压力从“单点拥堵”变成“多点分流”，同时缩短锁持有时间。
精准锁定：避免锁范围意外扩大
行锁失效往往不是因为没用，而是被“悄悄升级”或“误伤扩大”。常见原因包括：
- 查询未走索引——触发全表扫描，InnoDB 可能升级为间隙锁甚至表锁；
- WHERE 条件含函数或隐式类型转换（如 WHERE id = '123' 而 id 是 INT）；
- 使用 SELECT ... FOR UPDATE 时未明确指定主键或唯一索引列，导致锁住索引范围而非单行。
建议：执行前用 EXPLAIN 确认是否命中索引；UPDATE/DELETE 尽量基于主键或唯一键操作；避免在 WHERE 中对字段做运算。
分桶拆分：把一行变多行，物理分散竞争
对库存、计数器等典型热点行，直接改造存储结构最有效：
- 原表 product (id, stock) → 拆为 product_stock (product_id, bucket_id, stock)，bucket_id 取值 0–9；
- 扣减时随机或轮询选一个 bucket 执行 UPDATE ... WHERE product_id = ? AND bucket_id = ?；
- 查总数用 SUM(stock) GROUP BY product_id，业务语义不变，写压力自然降至约 1/10。
该方案无需引入新组件，兼容性强，已在电商秒杀、账户余额汇总等场景稳定运行。
应用层预分流：在数据库前建一道“缓冲阀”
不让所有请求直冲 DB，是缓解热点的第一道防线：
- 用户点击“下单”后，只向 Redis Streams 或 List 写入轻量事件，不立刻更新数据库；
- 后台消费者按可控速率（如每秒 300–500 条）批量拉取、校验并落库；
- 配合 Redis 原子命令（如 DECRBY）做库存预占，超卖在队列层快速拦截。
这既削峰填谷，又把长事务拆成多个短事务，显著降低锁冲突概率。
乐观锁+版本控制：用检查替代等待
适合更新频繁但实际冲突率不高的场景（如文章阅读数、用户积分）：
- 表中增加 version 字段，每次更新带条件 WHERE version = ?；
- 更新成功则 version += 1；失败说明已被修改，可重试或返回友好提示；
- 相比悲观锁，它不阻塞其他事务，锁持有时间趋近于零。
注意：需配合幂等设计，防止重试引发重复变更。
不复杂但容易忽略——真正卡住系统的，往往不是锁机制本身，而是锁被谁、在哪儿、以什么方式长时间握着。盯住热点、缩窄范围、打散压力、缩短时间，四者协同，行锁才能真正成为并发的助力，而不是瓶颈。
