mysql中的锁竞争与性能瓶颈分析
根本原因是锁等待链形成后事务在innodb_row_lock_waits中排队且默认50秒超时，长事务持X锁会导致并发事务阻塞；实操需查INNODB STATUS、避免混用业务逻辑、确认锁必要性、确保UPDATE走索引、统一访问顺序、拆分事务、捕获死锁重试，并综合排查I/O与缓存瓶颈。
为什么 SELECT ... FOR UPDATE 会卡住其他事务
根本原因不是“锁本身慢”，而是锁等待链形成后，后续事务在 innodb_row_lock_waits 计数器里排队，且默认不超时（innodb_lock_wait_timeout=50 秒）。一旦某行被长事务持有 X 锁，所有想加锁读/写的并发事务都会阻塞，直到超时或前序事务提交。
实操建议：
- 用
SHOW ENGINE INNODB STATUS\G
查看TRANSACTIONS部分，重点关注lock struct(s)和waiting for this lock to be granted行 - 避免在事务中混用
SELECT ... FOR UPDATE和非必要业务逻辑（比如发 HTTP 请求、调用外部服务） - 确认是否真需要行级锁：如果只是防止重复插入，
INSERT ... ON DUPLICATE KEY UPDATE或唯一索引+重试通常更轻量
UPDATE 语句没走索引导致全表锁升级
InnoDB 的行锁是建立在索引之上的。当 UPDATE 的 WHERE 条件未命中任何索引（或仅命中主键但用了函数/类型隐式转换），InnoDB 会退化为锁住所有扫描过的聚簇索引记录——实际效果接近表级锁，尤其在大表上极易引发大面积阻塞。
实操建议：
- 执行前必看
EXPLAIN输出：type字段不能是ALL或index（全索引扫描也算高风险），key字段必须显示实际使用的索引名 - 警惕隐式类型转换：比如
WHERE user_id = '123'（字段是BIGINT）会导致索引失效；应写成WHERE user_id = 123 - 对高频更新字段，确保有单独索引或复合索引的最左前缀覆盖，不要依赖联合索引中靠后的列
死锁日志里出现 lock_mode X locks rec but not gap 是什么含义
这表示当前事务持有一个记录锁（rec），但不包含间隙锁（gap），常见于唯一索引等值查询（如 WHERE id = 100）。它本身不危险，但若多个事务按不同顺序访问同一组唯一键，就容易触发死锁——因为 InnoDB 按主键顺序加锁，而事务请求顺序不一致。
实操建议：
- 统一 DML 操作的主键/索引访问顺序：例如批量更新时，
ORDER BY id ASC再执行，避免各事务随机跳着锁行 - 减少事务粒度：把一个大事务拆成多个小事务，降低锁持有时间与交叉概率
- 应用层捕获
Deadlock found when trying to get lock错误（错误码 1213），实现指数退避重试，而非直接报错
如何定位真实瓶颈：锁等待 vs 磁盘 I/O vs CPU
看到慢查询和锁等待增多，不能直接归因为“锁太多”。先排除硬件和配置层面干扰：比如 innodb 过小导致频繁刷脏页，或磁盘 I/O 延迟高（
iostat -x 1 查 %util 和 await）会拖慢事务提交速度，间接拉长锁持有时间。
实操建议：
- 查性能视图：
SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;
找出耗时最长的语句，再结合sys.schema_table_statistics看其锁等待占比 - 监控关键指标：
Innodb_row_lock_time_avg> 50ms 说明锁争用已显著；但若Innodb_buffer_pool_wait_free> 0 或Pages_read_per_sec持续偏高，优先优化缓存或 I/O - 临时降低隔离级别（如从
REPEATABLE READ改为READ COMMITTED）可减少间隙锁，但需确认业务能否接受不可重复读
锁竞争从来不是孤立问题——它总在事务设计、索引质量、硬件资源和隔离级别之间暴露真实短板。最容易被忽略的是：开发阶段用小数据集测试无锁冲突，上线后数据量增长十倍，原本安全的索引范围查询突然变*表扫描，锁升级随之而来。
