MySQL锁竞争优化核心是缩短锁持有时间、降低锁粒度、避免不必要锁及合理用索引；需缩短事务、移出非DB操作、批量写入、分批更新、确保索引命中、降隔离级别、拆分热点、优化表结构。
MySQL锁竞争主要发生在高并发写入或长事务场景下，核心优化方向是缩短锁持有时间、降低锁粒度、避免不必要锁，并合理使用索引。关键不在于“完全消除锁”，而在于让锁更快释放、更少冲突。
缩短事务执行时间
锁在事务提交（COMMIT）或回滚（ROLLBACK）时才释放，长时间运行的事务会持续持有锁，阻塞其他操作。
- 把非数据库操作（如HTTP调用、文件读写、复杂计算）移出事务体外
- 避免在事务中等待用户输入或外部响应
- 批量写入尽量用单条 INSERT ... VALUES (...), (...), (...) 而非多条独立 INSERT
- 大更新分批次处理，例如按主键ID分段 UPDATE，每次只改1000行并及时提交
确保 WHERE 条件走索引
没有索引的 WHERE 条件会导致全表扫描，InnoDB 会为扫描过的每行加记录锁（甚至升级为间隙锁），极大扩大锁范围。
- 用 EXPLAIN 检查 UPDATE/DELETE 语句是否命中索引，重点关注 type 字段（应为 const/ref/range，避免 ALL 或 index）
- 联合索引要注意最左前缀匹配，例如索引 (a,b,c)，WHERE b=1 AND c=1 不会走索引
- 避免在索引列上使用函数或隐式类型转换，如 WHERE DATE(create_time) = '2024-01-01' 会失效索引
合理选择隔离级别与锁类型
默认的 REPEATABLE READ 隔离级别会使用间隙锁（Gap Lock）防止幻读，但在多数业务中可降级为 READ COMMITTED，显著减少锁冲突。
- 确认业务能接受“不可重复读”，将隔离级别设为 READ COMMITTED（SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED）
- READ COMMITTED 下，普通 SELECT 不加锁；UPDATE/DELETE 只锁命中的行，不加间隙锁
- 避免滥用 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE，仅在真正需要强一致性时才显式加锁
- 若只需防止脏读，且无幻读敏感逻辑，可考虑 READ UNCOMMITTED（极少见，慎用）
优化表结构与查询设计
锁竞争常暴露底层设计问题，从源头减少争抢点比单纯调参更有效。
- 高频更新的计数字段（如浏览量、点赞数）单独拆到缓存（Redis）或汇总表，避免频繁更新主表
- 热点行（如商品库存、账户余额）通过分桶（sharding）分散，例如 user_id % 16 作为子账户编号
- 避免大字段（TEXT/BLOB）与高频更新字段放在同一张表，减少行锁影响范围
- 主键尽量用自增整型，避免 UUID 或字符串主键导致插入时的页分裂和间隙锁增多
