CentOS系统中MySQL锁机制深度剖析
一 概览与存储引擎差异
- 在 CentOS 上运行的 MySQL，锁机制主要由存储引擎决定：
- MyISAM、MEMORY 采用表级锁：开销小、加锁快、无死锁，但并发度低。
- InnoDB 支持行级锁与表级锁（默认行级），并发度高，但可能出现死锁。
- BDB 支持页级锁（粒度介于表与行之间）。
- 锁粒度与并发性对比：
锁粒度开销/速度死锁并发度典型引擎表级锁小/快否低MyISAM、MEMORY行级锁大/慢是高InnoDB页级锁中/中是中BDB
- 在 InnoDB 中，加锁实际上是“给索引加锁”，先通过二级索引定位，再回到主键索引（聚簇索引）访问记录，这也是索引设计影响锁冲突的关键点。
二、InnoDB锁类型及其受隔离级别的影响
- 基本锁类型
- 共享锁 S（读锁）：
SELECT ... LOCK IN SHARE MODE，可并发读，阻塞写。 - 排他锁 X（写锁）：
SELECT ... FOR UPDATE、UPDATE/DELETE/INSERT，阻塞其他事务的 S/X。 - 意向锁 IS/IX（表级）：事务准备在某些行加 S/X 时，先在表级声明意向，用于加速表级与行级锁的冲突检测，避免逐行扫描判断。
- 共享锁 S（读锁）：
- 行级锁细分类（InnoDB 特有）
- Record Lock（记录锁）：锁定索引记录本身。
- Gap Lock（间隙锁）：锁定索引记录之间的间隙，防止插入（在 RR 及以上隔离级别生效）。
- Next-Key Lock（下一键锁）：记录锁 + 间隙锁，InnoDB 默认的行锁实现，用于防止幻读。
- 隔离级别对锁的影响
- READ COMMITTED（RC）：通常只使用记录锁，减少间隙锁，降低锁冲突，但可能出现幻读。
- REPEATABLE READ（RR，默认）：启用间隙锁与Next-Key Lock，范围更新/删除/加锁读时锁住记录及间隙，防止插入，提升一致性。
三 常见加锁场景与 SQL 示例
- 快照读（普通
SELECT）：基于 MVCC 读取一致性视图，不加 S/X 锁，高并发读友好。 - 当前读（加锁读/写入）
- 共享锁：
SELECT ... LOCK IN SHARE MODE;（读-读不阻塞，读-写阻塞）。 - 排他锁：
SELECT ... FOR UPDATE;（读写均阻塞，常用于余额扣减、库存扣减）。
- 共享锁：
- 显式表锁（MyISAM 常用，InnoDB 仅在特殊维护场景使用）
LOCK TABLES t READ/WRITE; ... UNLOCK TABLES;- MyISAM 读锁可并发读、阻塞写；写锁阻塞读写。
- 全库只读（逻辑备份等）
FLUSH TABLES WITH READ LOCK;（FTWRL）使整个实例只读；- 也可
SET GLOBAL readonly=true，但异常断开不会自动恢复，风险更高。
- 索引对加锁范围的影响（关键）
- 条件走唯一索引/主键等值匹配：通常仅加记录锁（无间隙锁）。
- 条件走非唯一索引或范围条件：常加 Next-Key Lock，锁定命中记录及其间隙，可能“锁范围”。
- 条件未走索引：可能导致全表扫描，InnoDB 可能升级为更大范围锁定，表现为“类表锁”的阻塞现象。
四 死锁与锁等待的排查与优化
- 典型现象与处理
- 死锁：错误码 1213，InnoDB 会自动回滚代价较小的事务，应用需具备重试机制。
- 锁等待超时：错误码 1205（
Lock wait timeout exceeded），需缩短事务或优化访问路径。
- 常用诊断 SQL（InnoDB）
SHOW ENGINE INNODB STATUSG（查看最新死锁细节、事务与锁信息）SELECT * FROM information_schema.innodb_trx ORDER BY trx_started;（在跑事务）SHOW OPEN TABLES WHERE In_use > 0;（查看被占用的表）- 注：MySQL 8.0+ 建议使用
performance_schema.data_locks/data_lock_waits替代旧表。
- 优化与规避建议
- 为高频条件建立合适索引，尽量走主键/唯一索引，缩小锁范围。
- 保持短事务，尽早提交，减少锁持有时间。
- 统一访问顺序（如按主键/业务编号排序），降低死锁概率。
- 在 RC 隔离级别下可减少间隙锁，但需评估业务一致性影响。
- 批量更新分批提交，避免长事务与热点行争用。
- 避免无索引的大范围扫描与无意义的
LOCK IN SHARE MODE后升级为 X 锁的路径。
