MySQL 面试之事务和锁篇

钝悟...大约 26 分钟

MySQL 面试之事务和锁篇

MySQL 事务

扩展阅读：
MySQL 官方文档之 InnoDB 锁和事务模型open in new window

【简单】什么是事务，什么是 ACID？

事务指的是满足 ACID 特性的一组操作。事务内的 SQL 语句，要么全执行成功，要么全执行失败。可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。通俗来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。

ACID 是数据库事务正确执行的四个基本要素。

原子性（Atomicity）
- 事务被视为不可分割的最小单元，事务中的所有操作要么全部提交成功，要么全部失败回滚。
- 回滚可以用日志来实现，日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
一致性（Consistency）
- 数据库在事务执行前后都保持一致性状态。
- 在一致性状态下，所有事务对一个数据的读取结果都是相同的。
隔离性（Isolation）
- 一个事务所做的修改在最终提交以前，对其它事务是不可见的。
持久性（Durability）
- 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
- 可以通过数据库备份和恢复来实现，在系统发生奔溃时，使用备份的数据库进行数据恢复。

一个支持事务（Transaction）中的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性。

【中等】事务存在哪些并发一致性问题？

事务中存在的并发一致性问题有：

丢失修改
脏读
不可重复读
幻读

“丢失修改”是指一个事务的更新操作被另外一个事务的更新操作替换。

如下图所示，T₁ 和 T₂ 两个事务对同一个数据进行修改，T₁ 先修改，T₂ 随后修改，T₂ 的修改覆盖了 T₁ 的修改。

“脏读（dirty read）”是指当前事务可以读取其他事务未提交的数据。

如下图所示，T₁ 修改一个数据，T₂ 随后读取这个数据。如果 T₁ 撤销了这次修改，那么 T₂ 读取的数据是脏数据。

“不可重复读（non-repeatable read）”是指一个事务内多次读取同一数据，过程中，该数据被其他事务所修改，导致当前事务多次读取的数据可能不一致。

如下图所示，T₂ 读取一个数据，T₁ 对该数据做了修改。如果 T₂ 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

“幻读（phantom read）”是指一个事务内多次读取同一范围的数据，过程中，其他事务在该数据范围新增了数据，导致当前事务未发现新增数据。

事务 T₁ 读取某个范围内的记录时，事务 T₂ 在该范围内插入了新的记录，T₁ 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

【中等】长事务可能会导致哪些问题？

长事务可能会导致以下问题：

锁竞争与资源阻塞
- 长事务长时间持有锁，导致其他事务阻塞，增加系统等待时间，降低并发性能。
- 业务线程因数据库请求等待而阻塞，可能引发连锁反应（如服务雪崩），造成严重线上事故。
死锁风险增加 - 多个长事务互相等待对方释放锁，容易形成死锁，导致系统无法正常执行。
主从延迟问题 - 主库执行时间长，从库同步及重放耗时增加，导致主从数据长时间不一致。
回滚效率低下 - 长事务执行中途失败时，回滚操作会浪费已执行的资源与时间，影响系统效率。

【困难】事务的二阶段提交是什么？

事务的二阶段提交确保 redo log（重做日志） 和 binlog（二进制日志） 的一致性，防止崩溃恢复时出现数据丢失或不一致。

两阶段流程

Prepare 阶段（准备阶段） - InnoDB 写入 redo log，并标记为 prepare 状态（事务预提交，但未最终提交）。
Commit 阶段（提交阶段） - MySQL Server 写入 binlog（记录 DML 操作）。binlog 写入成功后，InnoDB 将 redo log 状态改为 commit，完成事务提交。

binlog 和 redo log 的区别

特性	redo log	binlog
所属层级	InnoDB 引擎层	MySQL Server 层
日志类型	记录数据页的物理日志	记录 DML/DDL 操作的逻辑日志
存储方式	固定大小，环形写入	追加写入，可无限增长
主要用途	崩溃恢复（保证数据持久性）	主从复制、数据恢复、备份

为什么需要二阶段提交？

无论是单独先写 redo log 或先写 binlog，都可能导致数据不一致：

先写 redo log，后写 binlog（宕机时 binlog 未写入） - redo log 恢复数据，但 binlog 缺失该事务 → 主从数据不一致。
先写 binlog，后写 redo log（宕机时 redo log 未写入） - binlog 有记录，但 redo log 未提交 → 数据库实际数据丢失，与 binlog 不一致。

为了解决以上问题，所以需要事务二阶段提交（repare → commit），以确保写入两日志的原子性。

二阶段提交如何保证一致性？

MySQL 崩溃恢复时，检查两日志状态：

redo log prepare，binlog 未写入 - 直接回滚（两日志均无有效记录）。
redo log prepare，binlog 已写入 - 对比两日志数据：
- 一致：提交事务（redo log commit）。
- 不一致：回滚事务（保证数据一致）。

【中等】有哪些事务隔离级别，分别解决了什么问题？

为了解决以上提到的并发一致性问题，SQL 标准提出了四种“事务隔离级别”来应对这些问题。事务隔离级别等级越高，越能保证数据的一致性和完整性，但是执行效率也越低。因此，设置数据库的事务隔离级别时需要做一下权衡。

事务隔离级别从低到高分别是：

读未提交（read uncommitted） - 是指，事务中的修改，即使没有提交，对其它事务也是可见的。
读已提交（read committed） - 是指，事务提交后，其他事务才能看到它的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。
- 读已提交解决了脏读的问题。
- 读已提交是大多数数据库的默认事务隔离级别，如 Oracle。
可重复读（repeatable read） - 是指：保证在同一个事务中多次读取同样数据的结果是一样的。
- 可重复读解决了不可重复读问题。
- 可重复读是 InnoDB 存储引擎的默认事务隔离级别。
串行化（serializable ） - 是指，强制事务串行执行，对于同一行记录，加读写锁，一旦出现锁冲突，必须等前面的事务释放锁。
- 串行化解决了幻读问题。由于强制事务串行执行，自然避免了所有的并发问题。
- 串行化策略会在读取的每一行数据上都加锁，这可能导致大量的超时和锁竞争。这对于高并发应用基本上是不可接受的，所以一般不会采用这个级别。

事务隔离级别对并发一致性问题的解决情况：

隔离级别	丢失修改	脏读	不可重复读	幻读
读未提交	✔️️️	❌	❌	❌
读已提交	✔️️️	✔️️️	❌	❌
可重复读	✔️️️	✔️️️	✔️️️	❌
可串行化	✔️️️	✔️️️	✔️️️	✔️️️

【中等】MySQL 的默认事务隔离级别是什么？为什么？

事务隔离级别等级越高，越能保证数据的一致性和完整性，但是执行效率也越低。因此，设置数据库的事务隔离级别时需要做一下权衡。

MySQL 中的事务功能是在存储引擎层实现的，并非所有存储引擎都支持事务功能。比如 MyISAM 引擎就不支持事务，这也是 MyISAM 被 InnoDB 取代的重要原因之一。

大部分数据库的默认隔离级别是“读已提交”。然而，InnoDB 的默认隔离级别是“可重复读”。这是为了兼容早期 binlog 的 statement 格式问题。如果使用可重复读以下的隔离级别，使用了 statement 格式的 binlog 会产生主从数据不一致的问题。

此外，在 InnoDB 中，可重复读隔离级别虽然不能解决幻读，但是可以很大程度的避免幻读的发生。根据不同的查询方式，分别提出了避免幻读的方案：

针对快照读（普通 select 语句），通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。
针对当前读（select ... for update 等语句），通过 Next-Key Lock（记录锁+间隙锁）方式解决了幻读，因为当执行 select ... for update 语句的时候，会加上 Next-Key Lock，如果有其他事务在 Next-Key Lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好了避免幻读问题。

很大程度的避免幻读，不代表完全解决幻读问题，下面是两个示例：

对于快照读，MVCC 并不能完全避免幻读现象。因为当事务 A 更新了一条事务 B 插入的记录，那么事务 A 前后两次查询的记录条目就不一样了，所以就发生幻读。
对于当前读，如果事务开启后，并没有执行当前读，而是先快照读，然后这期间如果其他事务插入了一条记录，那么事务后续使用当前读进行查询的时候，就会发现两次查询的记录条目就不一样了，所以就发生幻读。

【困难】MySQL 是如何实现事务的？

MySQL 主要是通过锁、Redo Log 、Undo Log、MVCC 来实现事务。

MySQL 利用锁（行锁、间隙锁等等机制），控制数据的并发修改，满足事务的隔离性。
Redo Log（重做日志），它会记录事务对数据库的所有修改，当 MySQL 发生宕机或崩溃时，通过重放 redo log 就可以恢复数据，用来满足事务的持久性。
Undo Log（回滚日志），它会记录事务的反向操作，简单地说就是保存数据的历史版本，用于事务的回滚，使得事务执行失败之后可以恢复之前的样子。实现原子性和隔离性
MVCC（多版本并发控制），满足了非锁定读的需求，提高了并发度，实现了读已提交和可重复读两种隔离级别，实现了事务的隔离性。

事务实现了原子性、隔离性和持久性特性后，本身就达到了一致性的目的。

【困难】什么是 MVCC？

MVCC 是 Multi Version Concurrency Control 的缩写，即“多版本并发控制”。MVCC 的设计目标是提高数据库的并发性，采用非阻塞的方式去处理读/写并发冲突，可以将其看成一种乐观锁。

不仅是 MySQL，包括 Oracle、PostgreSQL 等其他关系型数据库都实现了各自的 MVCC，实现机制没有统一标准。MVCC 是 InnoDB 存储引擎实现事务隔离级别的一种具体方式。其主要用于实现读已提交和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，要求很低，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。

MVCC 实现原理

MVCC 的实现原理，主要基于隐式字段、UndoLog、ReadView 来实现。

隐式字段

InnoDB 存储引擎中，数据表的每行记录，除了用户显示定义的字段以外，还有几个数据库隐式定义的字段：

row_id - 隐藏的自增 ID。如果数据表没有指定主键，InnoDB 会自动基于 row_id 产生一个聚簇索引。
trx_id - 最近修改的事务 ID。事务对某条聚簇索引记录进行改动时，就会把该事务的事务 id 记录在 trx_id 隐藏列里；
roll_pointer - 回滚指针，指向这条记录的上一个版本。

UndoLog

MVCC 的多版本指的是多个版本的快照，快照存储在 UndoLog 中。该日志通过回滚指针 roll_pointer 把一个数据行的所有快照链接起来，构成一个版本链。

ReadView

ReadView 就是事务进行快照读时产生的读视图（快照）。

ReadView 有四个重要的字段：

m_ids - 指的是在创建 ReadView 时，当前数据库中“活跃事务”的事务 ID 列表。注意：这是一个列表，“活跃事务”指的就是，启动了但还没提交的事务。
min_trx_id - 指的是在创建 ReadView 时，当前数据库中“活跃事务”中事务 id 最小的事务，也就是 m_ids 的最小值。
max_trx_id - 这个并不是 m_ids 的最大值，而是指创建 ReadView 时当前数据库中应该给下一个事务分配的 ID 值，也就是全局事务中最大的事务 ID 值 + 1；
creator_trx_id - 指的是创建该 ReadView 的事务的事务 ID。

在创建 ReadView 后，我们可以将记录中的 trx_id 划分为三种情况：

已提交事务
已启动但未提交的事务
未启动的事务

ReadView 如何判断版本链中哪个版本可见？

一个事务去访问记录的时候，除了自己的更新记录总是可见之外，还有这几种情况：

trx_id == creator_trx_id - 表示 trx_id 版本记录由 ReadView 所代表的当前事务产生，当然可以访问。
trx_id < min_trx_id - 表示 trx_id 版本记录是在创建 ReadView 之前已提交的事务生成的，当前事务可以访问。
trx_id >= max_trx_id - 表示 trx_id 版本记录是在创建 ReadView 之后才启动的事务生成的，当前事务不可以访问。
min_trx_id <= trx_id < max_trx_id - 需要判断 trx_id 是否在 m_ids 列表中
- 如果 trx_id 在 m_ids 列表中，表示生成 trx_id 版本记录的事务依然活跃（未提交事务），当前事务不可以访问。
- 如果 trx_id 不在 m_ids 列表中，表示生成 trx_id 版本记录的事务已提交，当前事务可以访问。

这种通过“版本链”来控制并发事务访问同一个记录时的行为就叫 MVCC（多版本并发控制）。

【困难】MVCC 实现了哪些隔离级别，如何实现的？

对于“读已提交”和“可重复读”隔离级别的事务来说，它们都是通过 MVCC 的 ReadView 机制来实现的，区别仅在于创建 ReadView 的时机不同。ReadView 可以理解为一个数据快照。

MVCC 如何实现可重复读隔离级别

可重复读隔离级别只有在启动事务时才会创建 ReadView，然后整个事务期间都使用这个 ReadView。这样就保证了在事务期间读到的数据都是事务启动前的记录。

举个例子，假设有两个事务依次执行以下操作：

初始，表中 id = 1 的 value 列值为 100。
事务 2 读取数据，value 为 100；
事务 1 将 value 设为 200；
事务 2 读取数据，value 为 100；
事务 1 提交事务；
事务 2 读取数据，value 依旧为 100；

以上操作，如下图所示。T2 事务在事务过程中，是否可以看到 T1 事务的修改，可以根据 ReadView 中描述的规则去判断。

从图中不难看出：

对于 trx_id = 100 的版本记录，比对 T2 事务 ReadView ，trx_id < min_trx_id，因此在 T2 事务中的任意时刻都可见；
对于 trx_id = 101 的版本记录，比对 T2 事务 ReadView ，可以看出 min_trx_id <= trx_id < max_trx_id ，且 trx_id 在 m_ids 中，因此 T2 事务中不可见。

综上所述，在 T2 事务中，自始至终只能看到 trx_id = 100 的版本记录。

MVCC 如何实现读已提交隔离级别

读已提交隔离级别每次读取数据时都会创建一个 ReadView。这意味着，事务期间的多次读取同一条数据，前后读取的数据可能会出现不一致——因为，这期间可能有另外一个事务修改了该记录，并提交了事务。

举个例子，假设有两个事务依次执行以下操作：

初始，表中 id = 1 的 value 列值为 100。
事务 2 读取数据（创建 ReadView），value 为 0；
事务 1 将 value 设为 100；
事务 2 读取数据（创建 ReadView），value 为 0；
事务 1 提交事务；
事务 2 读取数据（创建 ReadView），value 为 100；

以上操作，如下图所示，T2 事务在事务过程中，是否可以看到其他事务的修改，可以根据 ReadView 中描述的规则去判断。

从图中不难看出：

对于 trx_id = 100 的版本记录，比对 T2 事务 ReadView ，trx_id < min_trx_id，因此在 T2 事务中的任意时刻都可见；
对于 trx_id = 101 的版本记录，比对 T2 事务 ReadView ，可以看出第二次查询时（T1 更新未提交），min_trx_id <= trx_id < max_trx_id ，且 trx_id 在 m_ids 中，因此 T2 事务中不可见；而第三次查询时（T1 更新已提交），trx_id < min_trx_id，因此在 T2 事务中可见；

综上所述，在 T2 事务中，当 T1 事务提交前，可读取到的是 trx_id = 100 的版本记录；当 T1 事务提交后，可读取到的是 trx_id = 101 的版本记录。

MVCC + Next-Key Lock 如何解决幻读

MySQL InnoDB 引擎的默认隔离级别虽然是“可重复读”，但是它很大程度上避免幻读现象（并不是完全解决了），解决的方案有两种：

针对快照读（普通 SELECT 语句），通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。
针对当前读（SELECT ... FOR UPDATE 等语句），通过 Next-Key Lock（记录锁+间隙锁）方式解决了幻读，因为当执行 SELECT ... FOR UPDATE 语句的时候，会加上 Next-Key Lock，如果有其他事务在 Next-Key Lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好的避免了幻读问题。

【困难】各事务隔离级别是如何实现的？

四种隔离级别具体是如何实现的呢？

以 InnoDB 的事务实现来说明：

对于“读未提交”隔离级别的事务来说，因为可以读到未提交事务修改的数据，所以直接读取最新的数据就好了；
对于“串行化”隔离级别的事务来说，通过加读写锁的方式来避免并行访问；
对于“读提交”和“可重复读”隔离级别的事务来说，它们都是通过 ReadView 来实现的，区别仅在于创建 ReadView 的时机不同。ReadView 可以理解为一个数据快照。
- “读提交”隔离级别是在“每个语句执行前”都会重新生成一个 ReadView
- “可重复读”隔离级别是在“启动事务时”生成一个 ReadView，然后整个事务期间都在用这个 ReadView。

MySQL 锁

【中等】MySQL 中有哪些锁？

为了解决并发一致性问题，MySQL 支持了很多种锁来实现不同程度的隔离性，以保证数据的安全性。

独享锁和共享锁

独享锁（Exclusive）：简写为 X 锁，又称为“写锁”、“排它锁”。

特性
- 用于写入操作
- 完全排他，同一时间仅允许一个事务持有
加锁
- SELECT ... FOR UPDATE
- DML 语句（隐式加锁）

共享锁（Shared）：简写为 S 锁，又称为“读锁”。

特性
- 用于读取操作
- 允许多事务并发持有，互不阻塞
加锁
- SELECT ... LOCK IN SHARE MODE
- SELECT ... FOR SHARE（MySQL 8.0+）

存储引擎实现差异

MyISAM：仅支持表级锁
- LOCK TABLES ... READ → S 锁
- LOCK TABLES ... WRITE → X 锁
InnoDB：支持行级锁和表级锁
- 默认使用行锁（更细粒度）
- 特殊场景退化为表锁（如无索引更新）

悲观锁和乐观锁

基于加锁方式分类，MySQL 可以分为悲观锁和乐观锁。

悲观锁 - 假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作
- 在查询完数据的时候就把事务锁起来，直到提交事务（COMMIT）
- 实现方式：使用数据库中的锁机制。
乐观锁 - 假设最好的情况——每次访问数据时，都假设数据不会被其他线程修改，不必加锁。只在更新的时候，判断一下在此期间是否有其他线程更新该数据。
- 实现方式：更新数据时，先使用版本号机制或 CAS 算法检查数据是否被修改。

为什么要引入乐观锁？

乐观锁也是一种通用的锁机制，在很多软件领域，都存在乐观锁机制。

锁，意味着互斥，意味着阻塞。在高并发场景下，锁越多，阻塞越多，势必会拉低并发性能。那么，为了提高并发度，能不能尽量不加锁呢？

乐观锁，顾名思义，就是假设最好的情况——每次访问数据时，都假设数据不会被其他线程修改，不必加锁。虽然不加锁，但不意味着什么都不做，而是在更新的时候，判断一下在此期间是否有其他线程更新该数据。乐观锁最常见的实现方式，是使用版本号机制或 CAS 算法（Compare And Swap）去实现。

【示例】MySQL 乐观锁示例

假设，order 表中有一个字段 status，表示订单状态：status 为 1 代表订单未支付；status 为 2 代表订单已支付。现在，要将 id 为 1 的订单状态置为已支付，则操作如下：

select status, version from order where id=#{id}

update order
set status=2, version=version+1
where id=#{id} and version=#{version};

乐观锁的优点是：减少锁竞争，提高并发度。

乐观锁的缺点是：

存在 ABA 问题。所谓的 ABA 问题是指在并发编程中，如果一个变量初次读取的时候是 A 值，它的值被改成了 B，然后又其他线程把 B 值改成了 A，而另一个早期线程在对比值时会误以为此值没有发生改变，但其实已经发生变化了
如果乐观锁所检查的数据存在大量锁竞争，会由于不断循环重试，产生大量的 CPU 开销。

全局锁

全局锁是 MySQL 中一种锁住整个数据库实例的机制，使数据库处于只读状态，禁止所有数据修改操作（DML、DDL）。

加锁、解锁

加全局锁（Flush Tables With Read Lock, FTWRL）

FLUSH TABLES WITH READ LOCK;

阻塞所有 写操作（INSERT/UPDATE/DELETE） 和 DDL（ALTER/DROP），但允许读操作（SELECT）。

释放锁

UNLOCK TABLES;

应用场景

数据库备份（确保备份数据一致性）
主从同步初始化
防止数据修改（维护期间禁止写入）

表级锁

表锁：锁定整张表，是 MyISAM 引擎的默认锁类型，InnoDB 引擎在特定情况下也会使用。
- 表共享读锁（Table Read Lock）：LOCK TABLE table_name READ
  - 所有会话可以同时读取该表
  - 禁止任何会话写入（INSERT/UPDATE/DELETE）
  - 读锁之间不互斥（多个事务可同时持有读锁）
- 表独占写锁（Table Write Lock）：LOCK TABLE table_name WRITE
  - 仅允许当前会话读写该表
  - 其他会话无法读取或写入（完全排他）
  - 写锁与其他所有锁互斥（包括读锁和其他写锁）
元数据锁（Metadata Lock, MDL）：自动加锁，保护表结构，防止在查询或修改时表结构被更改。
- 增删改查，加读锁
- 结构变更，加写锁
意向锁（Intention Lock）：用于快速判断表中是否有行被锁定，从而优化锁冲突检测效率。
- 意向共享锁（IS）：表示事务准备在表的某些行上加 S 锁（共享锁），如 SELECT ... LOCK IN SHARE MODE。
- 意向独享锁（IX）：表示事务准备在表的某些行上加 X 锁（排他锁），如 SELECT ... FOR UPDATE 或 DML 操作。
自增锁（Auto Increment Lock）：确保并发插入时自增值的正确分配。
- 确保自增值连续：防止多个事务同时插入数据时，自增列出现重复或跳跃。
- 保证唯一性：避免并发插入时多个事务获取相同的自增值，导致主键冲突。
- 支持事务回滚：如果事务回滚，已分配的自增值不会回退，但后续插入仍会继续递增，确保不重复。

行级锁

记录锁（Record Lock）：锁定索引中的单条记录。
- 仅锁住符合条件的行，不影响其他行
- 如果表无索引，InnoDB 会退化为表锁
```
-- 对 id=1 的记录加锁
SELECT * FROM users WHERE id = 1 FOR UPDATE;
```
间隙锁（Gap Lock）：锁定索引记录之间的间隙，防止其他事务在这个范围内插入数据。
- 仅存在于可重复读隔离级别，为了解决幻读问题
```
-- 锁定 20-30 之间的间隙
SELECT * FROM users WHERE age BETWEEN 20 AND 30 FOR UPDATE;
```
临键锁（Next-Key Lock）：记录锁+间隙锁的组合，锁定记录及前面的间隙。
- InnoDB 默认的行锁方式
- 同时防止幻读和保证当前读的一致性
```
-- 锁定 id>10 的记录及后面的间隙
SELECT * FROM users WHERE id > 10 FOR UPDATE;
```
插入意向锁（Insert Intention Lock）：在 INSERT 操作前设置，表示准备插入
- 不阻塞其他插入意向锁
- 会等待间隙锁释放
```
-- 自动获取插入意向锁
INSERT INTO users VALUES (15, 'John');
```

【中等】死锁是如何产生的？

死锁是指，多个事务竞争同一资源，并请求锁定对方占用的资源，从而导致恶性循环的现象。

死锁产生条件（必须同时满足）

互斥：资源一次只能被一个事务占用（如行锁）。
占有并等待：事务持有资源的同时，等待其他事务释放资源。
不可强占：事务已获得的资源不能被强制抢占，只能主动释放。
循环等待：事务之间形成循环等待。

【困难】如何避免死锁？

死锁的四个必要条件：互斥、占有且等待、不可强占、循环等待。只要系统发生死锁，这些条件必然成立，但是只要破坏任意一个条件就死锁就不会成立。由此可知，要想避免死锁，就要从这几个必要条件上去着手：

更新表时，尽量使用主键更新，减少冲突；
避免长事务，尽量将长事务拆解，可以降低与其它事务发生冲突的概率；
设置合理的锁等待超时参数，我们可以通过 innodb_lock_wait_timeout 设置合理的等待超时阈值，特别是在一些高并发的业务中，我们可以尽量将该值设置得小一些，避免大量事务等待，占用系统资源，造成严重的性能开销。
在编程中尽量按照固定的顺序来处理数据库记录，假设有两个更新操作，分别更新两条相同的记录，但更新顺序不一样，有可能导致死锁；
在允许幻读和不可重复读的情况下，尽量使用读已提交事务隔离级别，可以避免 Gap Lock 导致的死锁问题；
还可以使用其它的方式来代替数据库实现幂等性校验。例如，使用 Redis 以及 ZooKeeper 来实现，运行效率比数据库更佳。

【困难】如何解决死锁？

当出现死锁以后，有两种策略：

设置事务等待锁的超时时间。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
开启死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过 50s 才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。但是，若直接把这个时间设置成一个很小的值，比如 1s，也是不可取的。当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。

所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且 innodb_deadlock_detect 的默认值本身就是 on。为了解决死锁问题，不同数据库实现了各自的死锁检测和超时机制。InnoDB 的处理策略是：将持有最少行级排它锁的事务进行回滚。主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的：每当事务被锁时，就要查看它所依赖的线程是否被其他事务锁住，如此循环，来判断是否出现了循环等待，也就是死锁。因此，死锁检测可能会耗费大量的 CPU。

参考资料

昵称

邮箱

网址

按正序
按倒序
按热度

MySQL 面试之事务和锁篇

# MySQL 面试之事务和锁篇

# MySQL 事务

# 【简单】什么是事务，什么是 ACID？

# 【中等】事务存在哪些并发一致性问题？

# 【中等】长事务可能会导致哪些问题？

# 【困难】事务的二阶段提交是什么？

# 【中等】有哪些事务隔离级别，分别解决了什么问题？

# 【中等】MySQL 的默认事务隔离级别是什么？为什么？

# 【困难】MySQL 是如何实现事务的？

# 【困难】什么是 MVCC？

# 隐式字段

# UndoLog

# ReadView

# 【困难】MVCC 实现了哪些隔离级别，如何实现的？

# 【困难】各事务隔离级别是如何实现的？

# MySQL 锁

# 【中等】MySQL 中有哪些锁？

# 独享锁和共享锁

# 悲观锁和乐观锁

# 全局锁

# 表级锁

# 行级锁

# 【中等】死锁是如何产生的？

# 【困难】如何避免死锁？

# 【困难】如何解决死锁？

# 参考资料

预览:

MySQL 面试之事务和锁篇

MySQL 事务

【简单】什么是事务，什么是 ACID？

【中等】事务存在哪些并发一致性问题？

【中等】长事务可能会导致哪些问题？

【困难】事务的二阶段提交是什么？

【中等】有哪些事务隔离级别，分别解决了什么问题？

【中等】MySQL 的默认事务隔离级别是什么？为什么？

【困难】MySQL 是如何实现事务的？

【困难】什么是 MVCC？

隐式字段

UndoLog

ReadView

【困难】MVCC 实现了哪些隔离级别，如何实现的？

【困难】各事务隔离级别是如何实现的？

MySQL 锁

【中等】MySQL 中有哪些锁？

独享锁和共享锁

悲观锁和乐观锁

全局锁

表级锁

行级锁

【中等】死锁是如何产生的？

【困难】如何避免死锁？

【困难】如何解决死锁？

参考资料