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

InnoDB中的锁

news 来源：原创 2025/5/31 16:40:54

InnoDB中的锁机制是MySQL中实现事务隔离和数据一致性的核心部分。它通过多种锁类型和等级，控制多个事务对同一数据的并发访问，保证数据的完整性与一致性。

主要锁类型

1.行锁（Row Lock）
- 定义：锁定单个行记录。InnoDB采用多版本并发控制（MVCC）结合行锁，支持高并发。
- 作用范围：单个行数据
- 类型：
  - 共享锁（S锁，共享锁）：允许多个事务同时读取（select … lock in share mode），但不允许修改。
  - 排他锁（X锁，排他锁）：事务可以修改行数据，其他事务既不能读取（除非使用更低隔离级别），也不能修改。
2 表锁（Table Lock）
- 比较少用，但在某些操作（如lock tables）会用到。
- 作用范围：整张表
- 作用：阻止其他事务对表的任何读写操作，确保完整一致性。

锁的粒度和等级

粒度
- 行级锁：锁定单个行，细粒度，支持高并发。
- 表级锁：锁定全表，粗粒度，适用于大量DML操作。
隔离级别对锁的影响

MySQL的事务隔离级别影响锁的行为：

Read Uncommitted：可能会读取未提交事务的行（脏读），锁较少。
Read Committed：只能读取已提交的行，使用行锁。
Repeatable Read（InnoDB默认）：通过MVCC和行锁实现，支持一致性读。
Serializable：最严格，几乎类似表锁，保证完全隔离。

锁的应用场景

select… for update：获得行的排他锁，阻止其他事务修改，常用于更新前锁定。
select … lock in share mode：获得共享锁，允许读取但阻止其他事务取得排他锁。

不同类型锁的特点

锁类型	作用范围	并发支持	特点
共享锁（S）	行或表	多事务可同时读	允许读取，不允许修改
排他锁（X）	行或表	不能同时读写	只允许自己操作，其他等待
意向锁（IS, IX）	表锁的辅助手锁	执行时帮助锁定层次关系	通知其他事务锁定意向
自增锁（NEXT KEY）	内部机制	维护自增主键唯一性	防止自增列出现重复

锁的兼容性与冲突

兼容性：如果事务获取了某个数据的共享锁，其他事务可以立即获得该数据的共享锁，这种情况叫锁兼容。如果事务获取了某个数据的共享锁或排他锁，其他事务想要获取该数据的排他锁，必须要等到该行的锁释放掉。

在这里插入图片描述

冲突：主要发生在：
- 一个事务试图获得排他锁，而另一个事务已持有共享锁或排他锁。
- 两个事务都试图获得互斥的锁。

死锁

当多个事务相互等待对方释放锁时，会发生死锁。
InnoDB检测到死锁后，会选择中断其中一个事务（回滚）解决。

条件

互斥条件：资源（锁）同时只能由一个事务使用。
占有并等待：一个事务至少持有一个资源，同时等待获取其他被占用资源。
非剥夺条件：已占有的资源不能强制收回，只能由持有事务主动释放。
循环等待条件：多个事务形成环状等待关系。

示例流程：

事务A：

锁住table1
等待锁住table2

事务B：

锁住table2
等待锁住table1

此时：

A等待B释放table2
B等待A释放table1

两个事务都在等待对方释放资源，导致僵局（死锁）。

MVCC（多版本并发控制）

InnoDB通过MVCC实现非锁定读（一致性读），大幅提升并发性能。
读操作不会等待写锁释放，而是读取数据的快照副本。
核心思想：每个数据行都存储多个版本（快照），不同事务可以看到不同的版本。

工作原理

版本控制：每次对数据的修改（INSERT、UPDATE、DELETE）都会生成一个新的版本。
版本识别：每个事务都有一个事务ID(TS)或时间戳。
读取数据：
读取操作根据事务的TS，只读取“版本号” ≤ 自己TS的最新版本。
这样，读取的是事务开始时“的视图”，实现一致性。

在InnoDB中实现

行版本存储：
- 每行除了实际数据，还有两个隐藏字段：
  - 创建版本（XMIN）：该版本由哪个事务创建。
  - 删除版本（XMAX）（可空）：标记哪个事务删除了这个版本。
事务管理：
- 事务有一个事务ID（或时间戳）。
  - 读取时，只访问那些版本号≤自己事务ID的最新版本。
  - 写入时，创建新的版本。

总结

MVCC让数据库在进行多事务同时读写时：
- 读操作不加锁（非锁定读）
- 写操作仍通过锁控制
- 不同事务可以“同时”访问不同版本的数据

这样极大提升了并发能力，并保证了事务的隔离性。

意向锁

InnoDB 允许事务在行锁和表锁同时存在。为支持在不同粒度上进行加锁，InnoDB 支持意向锁。
意向锁，将锁定的对象分为多个层级，意向锁意味着事务有意向在更细粒度上加锁。如果需要对行加锁，需要先对表加意向锁再对行加锁。

作用和目的

协调锁的层次关系：在InnoDB中，为了支持多粒度锁（表锁和行锁），需要用意向锁告诉其他事务：自己打算在某个部分（比如表的某个行）上加锁。
减少锁冲突：其他事务在请求锁时，通过判断意向锁，可以快速知道表是否已被部分锁定，从而避免不必要的等待。
避免死锁：通过表的意向锁协调不同粒度的锁请求，降低死锁风险。
意向锁的作用：如果没有意向锁，想要给一个表加表锁必须要检查该表是否有表锁和每一行是否有锁。而如果在加行锁前给这个表加上了意向锁，这时只需要检查表锁和意向锁就可以了，不需要检查每一行的锁。

常见的意向锁类型

锁类型	作用范围	数据库层次	描述
意向共享锁（IS，Intention Shared）	表	表锁	表明自己打算在某个或多个行上获取共享锁（S锁）
意向排他锁（IX，Intention Exclusive）	表	表锁	表明自己打算在某个或多个行上获取排他锁（X锁）

意向锁在 InnoDB 中就是表级别的锁，支持两种意向锁：

意向共享锁（IS Lock），事务有意向对表中某些行加共享锁
意向排他锁（IX Lock），事务有意向对表中某些行加排他锁

表级锁的兼容性在这里插入图片描述

注意：意向锁不会和行级锁冲突，意向锁之间也不会冲突，意向锁只会和共享表锁和排他表锁冲突

用法和流程

事务请求锁的流程
- 当事务要在表中的某些行上加锁（S或X锁）时，必须先在表上加对应的意向锁（IS或IX）。
这样做的好处：
- 其他事务可以通过意向锁快速得知表是否已有锁定意图，不会不必要地阻塞。
- 维护锁的层次结构和一致性。
实际操作中的表现
- 如果一个事务想要在某行上加S锁：它会在该行加共享锁，同时在对应的表上加意向共享锁（IS）（如果没有的话）。
- 如果一个事务想在行上加X锁：它会在该行加排他锁，同时在表上加意向排他锁（IX）。

示例

假设有两笔事务：

事务A打算在某行加X锁（X相当于写锁）
事务B想在该行加S锁（读取）

在加锁流程中：

事务A会在表上加IX锁。
事务A在目标行上加X锁。
事务B想在该行获取S锁时，会检查表的锁状态，发现表上有IX锁（由A持有），这表示有人在该表上准备加排他锁。
根据规则，B会等待A释放锁。

类似的，如果B试图在某行加S锁，且没有冲突的话，也会在表上加IS锁。

总结

特点	内容
作用	表明事务在表中的某些行上打算加锁，是一种“计划性”锁，用于锁层次协调。
类型	IS（意向共享锁）、IX（意向排他锁）
作用范围	仅在表级别，用于锁的层次协调
重要性	支持多粒度锁，避免锁冲突发生，提升系统并发能力

一致性非锁定读

特点

一致性非锁定读，读取正在执行 delete 和 update 操作的行时，不会等待该行上锁的释放，而是读取该行的一个快照数据（该行之前的版本）。非锁定读极大的提高了数据库的并发性，InnoDB 默认时这种读取方式，也就是说默认普通的 select 语句是不会加锁的，而是通过读取快照实现数据一致性。
上面提到的快照数据就是该行数据的历史版本，由此带来的并发控制称为多版本并发控制（MVCC）。
READ COMMITTED（以提交读）和 REPEATABLE READ（可重复读）在 InnoDB 中使用的是一致性非锁定读，但是读取的快照不同。提交读级别读取的是最新版本的快照，可重复读级别读取的是事务开始时数据的快照。

REPEATABLE READ（可重复读）

含义

事务开始时的快照在整个事务期间保持不变。
事务中多次读取同一数据，结果一致，即使其他事务也在修改。
InnoDB默认的隔离级别。

READ COMMITTED（已提交读）

含义

每次读取都是“当前事务开始时的快照”，但每次读取都会重新扫描最新的提交版本。
事务中多次读取相同数据，可能会得到不同的结果（如果其他事务提交了修改）。

区别：

特性	REPEATABLE READ	READ COMMITTED
读取快照	事务开始时的快照	每次读取时最新提交状态
重复读一致性	保持	不保证（可能不同）
读到的值	“快照”版本	最新提交值

在这里插入图片描述
可重复读级别通过读快照，可以解决前面提到的幻读问题，但是有些情况需要锁定读

原理

InnoDB为每个行文档都维护了隐藏的系统列（如DB_TRX_ID和DB_ROLL_PTR和版本信息）：
- DB_TRX_ID：标识该行最后一次被修改的事务ID
- DB_ROLL_PTR：指向旧版本的链表（多版本链）
当进行一致性非锁定读时：
- 读取只看自己事务开启时的“快照”中的版本，不会受其他未提交事务写操作的影响。
- 允许多个事务同时读数据，而不发生阻塞。

工作流程图

假设有两个事务：

时间点	操作描述
事务A开始	事务A开始对数据进行读取，读取点为“快照”时间
事务B提交	事务B对某行做了修改，提交成功
事务A继续读取	事务A读取数据时，看到的版本仍是事务开始时的快照（没有事务B的修改）

如果事务A执行SELECT，它会通过MVCC机制：

读取的是事务开始时的版本快照。
不加锁，不会阻塞其他写操作，也不会被其他写操作阻塞。

实现细节-快照一致性

事务开启时，系统会生成一个快照版本号（Snapshot Version）。
读取数据时，只会显示在自己快照版本之前（或等于自己快照版本）的版本。
即使其他事务修改数据，也不会影响正在读取的快照内容。

总结

特性	内容
非锁定	读操作不加锁，不阻塞其他事务，避免读写冲突。
一致性	读到的是自己事务开始时（或某个时间点）的“快照”，保证读的一致性。
依赖MVCC	通过维护多版本，实现多事务并发读写的高效隔离。
隔离级别	在`REPEATABLE READ`和`READ COMMITTED`中均支持，一致性非锁定读是它的基础。

一致性锁定读

InnoDB 默认使用一致性非锁定读。某些情况用户需要显式加锁保证数据的一致性，支持两种一致性锁定读的操作
- select … for update：对读取的行加一个排他锁
- select … lock in share mode：对读取的行加一个共享锁
如果只对读取的行加锁会有幻读问题：

在这里插入图片描述

锁定读时使用键值间隙锁（Next-Key Lock），就是行锁加间歇锁，可以解决幻读问题。
- Record Lock：单行记录的锁
- Gap Lock：间歇锁，锁定一个范围，但不包含记录本身
- Next-Key Lock：Gap Lock + Record Lock，锁定一个范围，并锁定记录本身
非锁定读使用快照和锁定读使用间歇锁可以基本解决幻读问题，但是极特殊情况还是有可能发生幻读。

在这里插入图片描述

特点

非锁定：读取操作不加锁，不阻塞其他事务。
一致性：读取数据是事务开始时的快照，不会受到其他已提交事务的影响。
**基于MVCC（多版本并发控制）**实现。

简单例子：

事务A开始，读取数据A，得到的版本是事务A开始时的快照。
其他事务（如B）可以在这期间修改数据并提交，事务A的读取不会受到影响。

与锁定读的区别

功能	一致性锁定读（快照读）	锁定读（如`SELECT ... FOR UPDATE`）
是否加锁	不加锁，非锁定	加锁（行锁或表锁）
阻塞情况	不阻塞	可能阻塞等待其他事务的释放
读到数据	事务开始时的快照	最新数据（可能被其他事务锁定阻塞）
适用场景	高并发、只读操作、保证一致性	更新、需要锁保证数据完整

一致性锁定读是锁定读中的一个类型
在一个事务中，先读到某个数据，然后修改它，为了确保在修改前，没有其他事务修改过，需要用到锁定读，避免“脏读”或“不可重复读”。

需求	方法	是否需要特殊操作	说明
一致性、非阻塞读	使用普通`select`	是，不需要	InnoDB的默认行为，保证读取时一致快照
需要锁定数据以防止其他修改	`select ... for update` 或 `lock in share mode`	需要	用于控制并发读写，保证数据一致性

一致性锁（非锁定读）与其他锁的基本关系

类型	作用	是否加锁	在什么场景使用	与其他锁关系
一致性非锁定读（快照读）	读到事务开始时的“快照”版本，不阻塞其他事务	不加锁（MVCC实现）	查询、统计、只读操作	不阻塞，也不被阻塞，支持高并发，保证数据一致性
锁定读取（行锁、表锁）	以锁定的方式读取，阻止其他事务读写	加锁（排他或共享）	更新数据、需要控制并发一致性	锁定读会阻塞其他写操作，或者等待其他事务释放锁
意向锁（IS、IX）	表层次上的“预备锁”，告诉其他事务你的计划	加在表上	支持多粒度锁、避免锁冲突	表级意向锁用于协调实际锁（比如行锁），避免冲突和死锁

关系

在实际操作中，当你用SELECT没有加任何锁时，InnoDB会选择使用快照读，这不是“锁”本身，而是用多版本机制保证数据一致。
如果你用SELECT … FOR UPDATE或LOCK IN SHARE MODE，则会执行锁定读，在数据上加锁，阻止其他事务同时修改或读取（取决于锁类型）。
意向锁是锁粒度的预备措施，帮助协调实际的行锁或表锁，不直接参与读操作，只是标明“我打算加锁”。
一致性锁（快照读）不用加锁，但依赖MVCC保证读取的一致性。
其他锁（行锁、表锁）会加锁，阻塞或等待，确保并发场景下数据的同步和一致。
两者在实际环境中配合使用：快照读提供高效的只读快照，锁定读用在需要确保强一致性或同步更新的场景。