MySQL InnoDB引擎的锁机制详解
MySQL InnoDB引擎的锁机制详解
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源(CPU、RAM、I/0)的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂
在MySQL中，按照锁粒度区分，分为三类：
- 全局锁：锁定数据库中的所有表
- 表级锁：每次操作锁住对应的一张表
- 行级锁：每次操作只锁住对应的行数据
全局锁
全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞
其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性
比如说对一个数据库中的所有表做备份，备份操作会依次将每一张表的数据和结构导出并保存，但是此时若是其他客户端突然对此数据库中的某些表进行了删除修改操作，导致已经备份的表和未备份的表发生数据不一致的情况
通过FLUSH TABLES WITH READ LOCK (FTWRL)命令，让数据库进入只读状态。就像给整个数据库按下暂停键：
-- 加全局锁
FLUSH TABLES WITH READ LOCK;
-- 执行备份操作
mysqldump -u root -p mydb > backup.sql
-- 释放锁
UNLOCK TABLES;
- 典型风险：
- 所有写操作将被阻塞（包括INSERT/UPDATE/DELETE）
- 长时间锁定可能导致业务停摆
- 主从同步延迟
表级锁
表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MISAM、InnoDB、BDB等存储引擎中
对于表级锁，主要分为以下三类：
- 表锁
- 元数据锁（meta data lock，MDL）
- 意向锁
表锁
对于表锁又分为两类：
-
表共享读锁，又称读锁（read lock）
-
表独占写锁，又称写锁（write lock）
- 手动加锁：通过
LOCK TABLES table_name READ/WRITE显式锁定。 - 自动释放：事务结束时自动释放。
两者之间就是经典读写锁之间的关系：
表加读锁时，其他线程再对表加读锁时不会被阻塞，而加写锁时会被阻塞
| 锁类型 | 读操作 | 写操作 |
|---|---|---|
| 读锁 | 允许 | 阻塞 |
| 写锁 | 阻塞 | 阻塞 |
元数据锁
元数据可以简单理解为表结构，元数据锁存在的作用主要就是为了维护表结构的数据一致性
当一张表中有未提交的事务，那么就不允许去修改本张表的表结构，为了避免DML与DDL的冲突，保证读写准确性
元数据锁加锁的过程是由系统自动控制的，不需要手动加锁
当对一张表进行增删改查的时候，加MDL读锁(共享)；当对表结构进行变更操作的时候，加MDL写锁(排他)
| 对应SQL | 锁类型 | 说明 |
|---|---|---|
| lock tables xxx read/write | SHARED_READ_ONLY/SHARED_NO_READ_WRITE | |
| select 、 select … lock in share mode | SHARED_READ | 共享锁、与SHARED READ、SHAREDWRITE兼容，与EXCLUSIVE互斥 |
| insert 、update、delete、select … for update | SHARED_WRITE | 共享锁、与SHARED READ、SHAREDWRITE兼容，与EXCLUSIVE互斥 |
| alter table … | EXCLUSIVE | 排他锁、与其他的MDL都互斥 |
意向锁
为了避免DML在执行时，加的行锁与表锁的冲突，在lnnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减
少表锁的检查
同样是有系统自动添加
- IS（意向共享锁）：由语句 select …lock in share mode添加
- IX（意向排他锁）：由insert、update、delete、select … for update 添加
兼容性规则
| 当前锁 \ 请求锁 | IS | IX | S | X |
|---|---|---|---|---|
| IS | ✔️ | ✔️ | ✔️ | ❌ |
| IX | ✔️ | ❌ | ❌ | ❌ |
| S | ✔️ | ❌ | ✔️ | ❌ |
| X | ❌ | ❌ | ❌ | ❌ |
这里的S与X是行级锁，可以参考下面的内容：
行级锁
行级锁，每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。应用在InnoDB存储引擎中。
InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁
对于行级锁，主要分为以下三类:
- 行锁（Record Lock）：锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。
- 间隙锁（GapLock）：锁定索引记录间隙(不含该记录)，确保索引记录间隙不变，防止其他事务在这个间隙进行inser，产生幻读。在RR隔离级别下都支持
- 临键锁（Next-KevLock）：行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。在RR隔离级别下支持。
行锁
InnoDB实现了以下两种类型的行锁:
- 共享锁(S):允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁
- 排他锁(X):允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁
加锁条件：
| SQL | 行锁类型 | 说明 |
|---|---|---|
| INSERT … | 排他锁 | 自动加锁 |
| UPDATE … | 排他锁 | 自动加锁 |
| DELETE … | 排他锁 | 自动加锁 |
| SELECT(正常) | 不加任何锁 | |
| SELECT … LOCK IN SHARE MODE | 共享锁 | 需要手动在SELECT之后加LOCK IN SHARE MODE |
| SELECT … FOR UPDATE | 排他锁 | 需要手动在SELECT之后加FOR UPDATE |
锁关系：
| 当前锁 \ 请求锁 | S锁 | X锁 |
|---|---|---|
| S锁 | ✔️ | ❌ |
| X锁 | ❌ | ❌ |
间隙锁/临键锁
默认情况下，InnoDB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key锁进行搜索和索引扫描，以防止幻读
- 索引上的等值查询(唯一索引)，给不存在的记录加锁时,优化为间隙锁
- 索引上的等值查询(普通索引)，向右遍历时最后一个值不满足查询需求时，next-kevlock退化为间隙锁
- 索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止
间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，，一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁
总结
| 锁类型 | 粒度 | 使用场景 | 注意事项 |
|---|---|---|---|
| 全局锁 | 全局 | 全库备份 | 导致全库只读，谨慎使用！ |
| 表级锁 | 表 | 结构变更、批量操作 | 避免长事务阻塞MDL写锁 |
| 行级锁 | 行 | 高并发场景下的数据修改 | 确保查询命中索引 |