锁争用本质是“等太久”而非“锁太多”，源于事务持锁时间长或热点资源争抢；通过查阻塞链、分析慢写SQL、监控锁等待统计可定位；优化索引、拆分事务、热点分段等分层缓解。
锁争用的本质：不是“锁太多”，而是“等太久”
高并发下性能骤降，常被归咎于“锁太多”，其实核心是事务持有锁的时间过长、或多个事务频繁争夺同一资源（如某条热点记录、某个索引页、甚至表元数据），导致大量线程阻塞排队。MySQL InnoDB 默认行级锁，但若查询未走索引、或使用范围条件（如 WHERE status IN (1,2)），可能升级为间隙锁或临键锁，锁住更大范围，加剧争用。
快速定位争用热点的三步法
不依赖猜测，用数据库原生工具抓关键证据：
-
查当前阻塞链：执行 SELECT * FROM information_schema.INNODB_TRX 查活跃事务；再连查 INNODB_LOCK_WAITS 和 INNODB_LOCKS（MySQL 5.7）或 performance_schema.data_locks（8.0+），直接看到谁在等谁、等哪条记录
-
找慢且高频的写SQL：从慢查询日志（slow_query_log）中筛选 Rows_examined 高 + Rows_affected 小 的 UPDATE/DELETE，这类语句常因扫描多却只改少量行，持锁时间长
-
看锁等待统计趋势：监控 Innodb_row_lock_waits 和 Innodb_row_lock_time_avg（通过 SHOW STATUS），若平均等待时间持续 > 50ms，说明已成瓶颈
缓解策略：按成本与效果分层落地
优先选低侵入、见效快的方案，再考虑架构调整：
-
SQL与索引优化（立竿见影）：确保所有写操作 WHERE 条件都命中索引；避免 UPDATE ... SET x=x+1 WHERE id=? 这类无谓更新；对高频更新字段（如库存 count），改用 INSERT ... ON DUPLICATE KEY UPDATE 替代先查后更
-
事务粒度控制（关键习惯）：把大事务拆成小事务；业务逻辑中非DB操作（如发消息、调外部API）移出事务体；必要时用 SELECT ... FOR UPDATE NOWAIT 主动失败，而非无限等待
-
热点隔离（治本之策）：对账户余额、商品库存等典型热点，引入分段计数（如将1个库存字段拆为16个 shard_count 字段，更新时随机选一个加减），或改用 Redis 原子操作预扣减，DB层异步落库
别忽略的隐性放大器
以下行为会无意放大锁影响，常被忽视：
- 应用端连接池配置过大（如 HikariCP maximumPoolSize=100），导致瞬间涌进大量请求，锁队列雪崩式堆积
- ORM 框架自动生成 SQL 未显式指定索引，或开启二级缓存但缓存穿透后批量打到DB，形成突发热点
- 备份或分析型查询（如 SELECT COUNT(*) FROM huge_table）未加 READ UNCOMMITTED 隔离级别，长期持有表级读锁
