关于 MySQL 的锁，你真的分清楚了吗？

关于 MySQL 的锁你真的分清楚了吗MySQL 的锁机制是保证数据库在并发环境下数据一致性和完整性的核心。理解锁对于优化 SQL 性能、避免死锁以及设计高并发系统至关重要。以下我将从锁的粒度、锁的类型、InnoDB 引擎的锁算法、隔离级别与锁的关系、以及死锁与优化这几个维度详细讲解。一、锁的粒度 (Lock Granularity)锁的粒度决定了锁住数据范围的大小。粒度越大并发度越低但开销越小粒度越小并发度越高但开销越大。1. 表级锁 (Table Lock)特点开销小加锁快不会出现死锁。但锁定粒度大发生锁冲突的概率最高并发度最低。适用场景MyISAM 引擎默认使用表锁InnoDB 在某些特定情况如全表扫描无索引下也会退化为表锁。类型表共享读锁 (Table Read Lock)其他事务可以读但不能写。表独占写锁 (Table Write Lock)其他事务不能读也不能写。2. 行级锁 (Row Lock)特点开销大加锁慢会出现死锁。但锁定粒度最小发生锁冲突的概率最低并发度最高。适用场景InnoDB 引擎支持行锁。注意InnoDB 的行锁是锁在索引上的。如果 SQL 语句没有走索引InnoDB 会升级为表锁。3. 页级锁 (Page Lock)特点介于表锁和行锁之间。一次锁定相邻的一组记录。适用场景BDB 引擎现在很少用MySQL 主流是 InnoDB行锁和 MyISAM表锁。二、锁的模式 (Lock Modes)主要针对 InnoDB 引擎分为两大类1. 共享锁 (Shared Lock, S 锁)含义又称读锁。允许事务读一行数据。兼容性一个事务获取了 S 锁其他事务也可以获取 S 锁但不能获取 X 锁。SQL 示例SELECT ... LOCK IN SHARE MODE(MySQL 8.0 后改为SELECT ... FOR SHARE)。2. 排他锁 (Exclusive Lock, X 锁)含义又称写锁。允许事务更新或删除一行数据。兼容性一个事务获取了 X 锁其他事务不能获取 S 锁或 X 锁。SQL 示例UPDATE,DELETE,INSERT,SELECT ... FOR UPDATE。3. 意向锁 (Intention Lock)含义表级锁。InnoDB 支持多粒度锁定为了快速判断表中是否有行锁引入了意向锁。类型意向共享锁 (IS)事务打算给数据行加 S 锁。意向排他锁 (IX)事务打算给数据行加 X 锁。作用如果有人在表上加了表级 X 锁InnoDB 会检查是否有 IS/IX 锁。如果有说明有人在用行锁表锁申请需等待。这避免了遍历所有行来判断是否可加表锁。三、InnoDB 的锁算法 (核心难点)InnoDB 实现了以下三种行锁算法这是面试和实际开发中最容易出问题的地方。1. 记录锁 (Record Lock)定义锁定索引记录本身。场景SELECT ... FOR UPDATE查询唯一索引的等值匹配。注意如果表没有索引InnoDB 会使用隐藏的行 ID 进行记录锁实际上等同于锁全表。2. 间隙锁 (Gap Lock)定义锁定索引记录之间的间隙或者第一条记录之前、最后一条记录之后的间隙。不包含记录本身。目的防止幻读Phantom Read。即防止其他事务在间隙中插入新数据。场景范围查询Range Query。例如WHERE id 10 AND id 20。副作用间隙锁会阻塞其他事务在间隙中INSERT数据严重影响并发插入性能。3. 临键锁 (Next-Key Lock)定义记录锁 间隙锁。锁定索引记录本身以及之前的间隙。场景默认情况下InnoDB 在Repeatable Read (RR)隔离级别下使用非唯一索引进行等值或范围查询时会使用 Next-Key Lock。目的同时防止修改已有数据和插入新数据解决幻读。四、隔离级别与锁的关系MySQL 有四种隔离级别锁的行为大不相同隔离级别脏读不可重复读幻读锁的行为特点Read Uncommitted可能可能可能几乎不加锁性能最高数据最不安全。Read Committed (RC)不可能可能可能快照读不加锁。当前读只加 Record Lock不加 Gap Lock。并发度高。Repeatable Read (RR)不可能不可能不可能默认级别。当前读默认使用 Next-Key Lock (Record Gap)防止幻读。Serializable不可能不可能不可能所有读操作都加锁相当于串行执行性能极低。关键区别 (RC vs RR)在RC级别下SELECT ... FOR UPDATE如果查询id 10只锁住id10这一行。在RR级别下同样的查询如果id不是唯一索引可能会锁住id10以及它周围的间隙Next-Key Lock防止别人插入id10附近的数据。五、常见锁问题与死锁1. 死锁 (Deadlock)定义两个或多个事务互相持有对方需要的锁并等待对方释放形成循环等待。经典案例事务 A锁住行 1想锁行 2。事务 B锁住行 2想锁行 1。InnoDB 处理检测到死锁后会回滚其中一个事务通常是回滚代价较小的那个。避免策略保持多个表/行的访问顺序一致。大事务拆分成小事务。在 RC 隔离级别下减少 Gap Lock。使用唯一索引查询避免 Next-Key Lock 退化为 Gap Lock。2. 锁等待 (Lock Wait)事务请求锁时如果锁被占用会进入等待状态。超过innodb_lock_wait_timeout(默认 50 秒) 会报错。六、如何查看与分析锁1. 查看正在等待锁的事务-- MySQL 5.7 / 8.0SELECT*FROMperformance_schema.data_lock_waits;2. 查看当前持有的锁-- MySQL 8.0SELECT*FROMperformance_schema.data_locks;3. 查看死锁日志SHOWENGINEINNODBSTATUS;-- 在输出结果中寻找 LATEST DETECTED DEADLOCK 部分4. 查看锁等待情况 (Sys 库)SELECT*FROMsys.schema_table_lock_waits;七、锁优化最佳实践尽可能使用索引InnoDB 行锁是锁在索引上的。如果不走索引行锁会升级为表锁导致性能急剧下降。使用EXPLAIN检查 SQL 是否命中索引。缩小锁范围只更新必要的行避免全表更新。将大事务拆分为小事务尽快提交Commit释放锁。降低隔离级别 (如果业务允许)将 RR 降级为 RC。RC 级别下没有 Gap Lock并发插入性能更好且能减少死锁概率。避免范围查询加锁在 RR 级别下范围查询,,BETWEEN会触发 Gap Lock 或 Next-Key Lock阻塞插入。如果可能改为等值查询。固定访问顺序如果业务逻辑需要同时更新多行或多表确保所有事务都按照相同的顺序访问资源这是避免死锁最有效的方法。使用SELECT ... FOR UPDATE需谨慎确保查询条件走唯一索引。如果只是为了防并发修改考虑使用乐观锁CAS 机制如version字段。总结MyISAM只有表锁InnoDB支持行锁。InnoDB 行锁依赖于索引无索引则锁全表。RR 隔离级别下非唯一索引的查询会加Next-Key Lock(包含间隙)容易导致性能问题和死锁。RC 隔离级别下只加Record Lock并发更好是互联网高并发场景的推荐选择。排查锁问题主要靠SHOW ENGINE INNODB STATUS和performance_schema表。理解这些机制相信你不仅是一个八股小能手更是一位数据库Infra 大神。