减少MySQL锁竞争的核心是缩小锁粒度、缩短持有时间、避免升级、合理设计事务；需降隔离级、拆小事务、精准索引、用乐观锁及缓存，并通过INNODB STATUS等工具监控优化。
减少 MySQL 锁竞争的核心在于：缩小锁粒度、缩短锁持有时间、避免锁升级、合理设计事务边界。高并发场景下，锁争用往往是性能瓶颈的直接原因，而非 CPU 或磁盘 IO。
选择合适的隔离级别和事务粒度
默认的 REPEATABLE READ 在某些更新场景下会使用间隙锁（Gap Lock），扩大锁范围；若业务能容忍幻读，可降级为 READ COMMITTED，它不加间隙锁，显著减少锁冲突。同时，事务务必“小而快”——只包含必要 SQL，避免在事务中做 RPC 调用、文件读写或 sleep 操作。
- 用
SELECT ... FOR UPDATE前先确认是否真需要排他锁，有时SELECT ... LOCK IN SHARE MODE或应用层校验更轻量 - 批量更新尽量拆成小批量（如每次 100~500 行），避免单个事务锁住大量记录
- 避免在事务中执行
SELECT * FROM t WHERE ...后再判断逻辑——可能触发全表扫描+锁表，应改用带明确主键/索引条件的精准更新
优化索引与查询，避免锁升级和隐式锁扩大
没有索引的 WHERE 条件会导致 MySQL 对扫描到的每行加锁，甚至升级为表锁（尤其 MyISAM）或大量行锁（InnoDB）。锁范围还受聚簇索引影响：更新非唯一二级索引列时，InnoDB 可能先锁二级索引记录，再回表锁主键，形成“双锁”。
- 确保
UPDATE/DELETE的WHERE条件命中有效索引（用EXPLAIN验证key和rows） - 高频更新字段尽量建在联合索引前列，或单独建索引，避免因索引缺失导致全行扫描锁
- 避免
OR、函数包裹字段（如WHERE DATE(create_time) = '2024-01-01'）、LIKE '%xxx'等导致索引失效的操作
用乐观锁替代悲观锁，或引入缓存层分流
对“读多写少”且更新逻辑简单（如计数器、状态位）的场景，可用版本号（version 字段）或 CAS（Compare-And-Swap）方式实现乐观锁，把锁冲突从数据库转移到应用层重试逻辑，大幅降低 DB 锁压力。
- 示例：
UPDATE order SET status = 2, version = version + 1 WHERE id = 123 AND version = 5，检查ROW_COUNT()是否为 1 决定是否重试 - 用户余额、库存等强一致性要求场景，可结合 Redis + Lua 做预扣减，MySQL 仅做最终落库，减少热点行更新频次
- 对非强实时报表类查询，优先走只读从库或本地缓存，避免与写请求争抢主库行锁
监控与定位真实锁瓶颈
别靠猜测——用 MySQL 原生工具看清谁在锁、锁了什么、等了多久：
-
SHOW ENGINE INNODB STATUS/G查看最新死锁日志和当前等待事务 -
SELECT * FROM performance_schema.data_locks（8.0+）或information_schema.INNODB_TRX+INNODB_LOCK_WAITS分析锁等待链 - 开启
innodb_status_output_locks并定期采集，配合 pt-deadlock-logger 分析历史死锁模式 - 慢查日志中关注
Rows_examined远大于Rows_sent的语句——大概率存在锁扫描放大问题
锁优化不是一劳永逸，而是持续观察、小步迭代的过程。重点盯住 QPS 上升后锁等待时间（Innodb_row_lock_time_avg）是否陡增，再针对性调整。