当前位置：首页 > news >正文

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

news 2026/5/11 13:26:21

MySQL 的锁机制是保证数据库在并发环境下数据一致性和完整性的核心。理解锁对于优化 SQL 性能、避免死锁以及设计高并发系统至关重要。

以下我将从锁的粒度、锁的类型、InnoDB 引擎的锁算法、隔离级别与锁的关系、以及死锁与优化这几个维度详细讲解。

锁的粒度决定了锁住数据范围的大小。粒度越大，并发度越低，但开销越小；粒度越小，并发度越高，但开销越大。

特点：开销小，加锁快，不会出现死锁。但锁定粒度大，发生锁冲突的概率最高，并发度最低。
适用场景：MyISAM 引擎默认使用表锁；InnoDB 在某些特定情况（如全表扫描无索引）下也会退化为表锁。
类型：
- 表共享读锁 (Table Read Lock)：其他事务可以读，但不能写。
- 表独占写锁 (Table Write Lock)：其他事务不能读也不能写。

主要针对 InnoDB 引擎，分为两大类：

含义：又称读锁。允许事务读一行数据。
兼容性：一个事务获取了 S 锁，其他事务也可以获取 S 锁，但不能获取 X 锁。
SQL 示例：SELECT ... LOCK IN SHARE MODE(MySQL 8.0 后改为SELECT ... FOR SHARE)。

含义：表级锁。InnoDB 支持多粒度锁定，为了快速判断表中是否有行锁，引入了意向锁。
类型：
- 意向共享锁 (IS)：事务打算给数据行加 S 锁。
- 意向排他锁 (IX)：事务打算给数据行加 X 锁。
作用：如果有人在表上加了表级 X 锁，InnoDB 会检查是否有 IS/IX 锁。如果有，说明有人在用行锁，表锁申请需等待。这避免了遍历所有行来判断是否可加表锁。

InnoDB 实现了以下三种行锁算法，这是面试和实际开发中最容易出问题的地方。

定义：记录锁 + 间隙锁。锁定索引记录本身以及之前的间隙。
场景：默认情况下，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，只锁住id=10这一行。
在RR级别下，同样的查询，如果id不是唯一索引，可能会锁住id=10以及它周围的间隙（Next-Key Lock），防止别人插入id=10附近的数据。

定义：两个或多个事务互相持有对方需要的锁，并等待对方释放，形成循环等待。
经典案例：
- 事务 A：锁住行 1，想锁行 2。
- 事务 B：锁住行 2，想锁行 1。
InnoDB 处理：检测到死锁后，会回滚其中一个事务（通常是回滚代价较小的那个）。
避免策略：
- 保持多个表/行的访问顺序一致。
- 大事务拆分成小事务。
- 在 RC 隔离级别下（减少 Gap Lock）。
- 使用唯一索引查询（避免 Next-Key Lock 退化为 Gap Lock）。

-- MySQL 5.7+ / 8.0SELECT*FROMperformance_schema.data_lock_waits;

-- MySQL 8.0+SELECT*FROMperformance_schema.data_locks;

SHOWENGINEINNODBSTATUS;-- 在输出结果中寻找 "LATEST DETECTED DEADLOCK" 部分

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字段）。