合理设计索引可确保行锁精准命中，避免全表扫描导致锁冲突；联合索引遵循最左前缀原则，利用EXPLAIN验证执行计划；缩短事务时间，避免耗时操作，尽早提交；优先按主键更新以减少锁开销；拆分热点数据或使用乐观锁降低争用；根据业务需求选择READ COMMITTED隔离级别以减少间隙锁；通过SHOW ENGINE INNODB STATUS、performance_schema等工具监控锁问题，定位并优化长事务和死锁。
MySQL行锁能有效提升并发性能，但使用不当容易引发锁等待、死锁等问题。减少行锁冲突的核心在于精准控制锁的范围、时长和事务行为。以下是一些实用优化策略。
合理设计索引以支持行锁命中
行锁的前提是InnoDB能准确锁定目标行。若SQL未命中索引，可能升级为间隙锁或表级扫描锁，大幅增加冲突概率。
- 确保WHERE条件中的字段有合适的索引，避免全表扫描触发大量行加锁
- 联合索引要符合最左前缀原则，保证查询能高效定位数据行
- 利用EXPLAIN分析执行计划，确认是否走索引并精确到行
缩短事务执行时间
锁持有时间越长，其他事务等待概率越高。应尽量减少事务中不必要的操作。
- 避免在事务中执行耗时逻辑，如网络请求、复杂计算
- 尽早提交事务，不要将无关操作包裹在同一事务内
- 读操作尽量放在事务外，特别是不需一致性读的场景
按主键或唯一索引更新数据
InnoDB通过主键聚簇索引管理数据，按主键更新可直接定位，减少锁路径和锁类型复杂度。
- 优先使用主键进行UPDATE/DELETE，避免二级索引带来的额外锁开销
- 若必须用非唯一索引，注意可能引入间隙锁（Gap Lock），增加死锁风险
避免热点行竞争
某些数据行被频繁修改（如计数器、状态字段），极易成为锁争用瓶颈。
- 考虑拆分热点数据，例如将单行计数器改为多行分片累加
- 批量更新代替频繁单行更新，降低锁申请频率
- 使用乐观锁替代悲观锁，在低冲突场景更高效
合理设置隔离级别
不同隔离级别影响锁的行为。高隔离级别会增加锁类型和范围。
- 如非必要，使用READ COMMITTED而非REPEATABLE READ，减少间隙锁使用
- 在RC级别下，InnoDB仅在当前SQL语句期间持锁，事务提交后即释放
监控与排查锁问题
及时发现锁冲突源头是优化前提。
- 通过SHOW ENGINE INNODB STATUS查看最近死锁信息
- 启用performance_schema或information_schema中的元数据锁表进行分析
- 记录慢查询日志，识别长时间持有锁的SQL
基本上就这些。关键是让锁尽可能快进快出，精准作用于目标行，同时避免系统性瓶颈。优化过程中结合实际业务场景调整，效果更明显。
