三、MySQL并发控制、事务与隔离级别_头歌 mysql开发技巧

本文链接：https://blog.youkuaiyun.com/sun_lm/article/details/120191357

本文详细介绍了MySQL的并发控制机制，包括读写锁、锁粒度，以及多版本并发控制（MVCC）。讨论了事务的四大特性：原子性、一致性、隔离性和持久性，并详细阐述了事务的四种隔离级别及其可能导致的并发问题。此外，还讲解了MySQL验证事务隔离级别的方法、死锁现象以及事务日志的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

当有多个连接对MySQL表中数据进行并发读写时，就会产生并发问题。为了避免并发问题，MySQL中引入了相关的锁。

1、MySQL的锁机制

1.1、读写锁

当多个客户端同时读取表中的数据时，不会产生并发问题。但是当有客户端在写入数据时，其他客户端来读取数据就会产生并发问题。为了提高并发程度，MySQL中使用了读写锁的机制。

读锁（共享锁）：读锁是共享的，读锁之间是相互不阻塞的。多个客户端在同一时刻可以共同读取同一资源。

写锁（排它锁）：写锁是互斥的，一个写锁会阻塞其他的写锁和读锁。

一个用户加了写锁之后，其他用户不能写入，也不能读取；一个用户加了读锁后，其他用户可以读取，但是不能写入。

1.2、锁粒度

通常来说，锁的粒度越大，锁住的资源越多，并发程度越低，但是越安全。MySQL中每个存储引擎都各自实现了自己的锁策略，其中InnoDB的锁机制包括表锁和行锁。

表锁：锁定整张表，是最基本的锁策略。MySQL的存储引擎层和服务器层都实现了表锁。

行锁：锁定某一行，可以最大程度的支持并发。行锁只在存储引擎中实现，而服务器层没有实现。

2、MySQL多版本并发控制（MVCC）

InnoDB中，为了提高并发程度，除了实现表锁之外，还提供了多版本并发控制（Multi Version Concurrency Control， MVCC）。MVCC可以理解为是一种特殊的行锁，且类似于乐观锁。在很多情况下能够避免加锁操作，实现非阻塞的读，而写入时也只需要对指定的某一行进行加锁。

MVCC是通过保存数据在某个时间点的快照来实现的。因此，在同一个事务中，能够保证多次读取的数据是一致的，不会出现不可重复读的问题，实现了可重复读的隔离级别，这也是MySQL（InnoDB）中事务默认的隔离级别。

对于MVCC，不同存储引擎可以有不同的实现。InnoDB实现MVCC的基本原理如下：在每行数据的后面，保存两个隐藏列，这两列中分别存储了这一行的创建时间、过期时间（删除时间）。这两列存储的并非是实际的时间的值，而是存储的一个系统版本号。也就是说，InnoDB为每行数据保存了两个版本号：创建版本号、删除版本号。

每开始一个事务，系统版本号都会自动递增。同时，事务开始时刻的系统版本号会作为这个事务的版本号，事务版本号用于查询时和系统版本号进行比较。

InnoDB事务默认的隔离级别是可重复读，在这个隔离级别下，InnoDB在增删改查时基本原理如下：

查询（select）：

创建版本号：只会读取创建版本号小于或等于当前事务版本号的数据行。这样能够保证事务中读取到的数据要么是在事务开始前就已经修改过的，要么就是在本事务中被修改的。而事务开始后，被其他事务修改后的数据是不会被读取到的，因为它们的创建版本号一定是大于当前事务版本号的。删除版本号：只能读取到删除版本号是无效值，或者删除版本号大于当前事务版本号的记录行。否则，说明该行在本事务之前已经被删除。

插入（insert）：将当前的系统版本号保存到行的创建版本号中。

删除（delete）：将当前的系统版本号保存到行的删除版本号中，作为删除标识。

更新（update）：新插入一条记录，并将当前的系统版本号保存到新行的创建版本号中；同时，将当前的系统版本号保存到原来的行的删除版本号中，作为旧行的删除标识。

得益于额外保存的这两个版本号，InnoDB中对于大多数操作都可以在不加锁的情况下进行。并且能够保证读取的数据都是正确的。缺点就是InnoDB需要为这两列做一些额外的维护操作。

InnoDB中，MVCC只能在读已提交和可重复读这两个隔离级别中起作用，而与其他两个隔离级别不兼容。因为读未提交永远都是读取最新版本号的行，不会用到这两个版本号；而串行化则会为所有读取的行都进行加锁，也没有必要使用这两个版本号。

3、事务的特性

数据库的事务可以简单理解为是一组SQL语句。对于事务内的SQL语句，要么全部执行成功，要么全部执行失败。事务具有四大特性（ACID）：

3.1、原子性（Atomicity）

一个事务是一个不可分割的最小工作单元，事务包含的所有操作要么全部提交成功，要么全部失败回滚。

3.2、一致性（Consistency）

数据库总是从一个一致性状态转换到另一个一致性状态。

拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，也就是说，数据总是从一个一致性状态转换到另一个一致性状态，这就是事务的一致性。

3.3、隔离性（Isolation）

事务的隔离性指的是，当并发产生多个事务时，各个事务相互之间相互隔离、互不影响。对于隔离性来说，数据库可以设置不同的隔离级别，隔离级别越高，事务之间的相互影响程度就越低，但是并发程度也会随之下降。

3.4、持久性（Durability）

一旦事务提交，所做的修改就会永久保存在数据库中。

4、事务的隔离级别

4.1、并发问题

在了解事务的隔离级别之前，首先了解一下在并发事务中存在的问题：

4.1.1、脏读

事务A读取了事务B已修改但未提交的数据。

4.1.2、不可重复读

事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。

4.1.3、幻读

例如，事务A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是事务B就在这个时候插入了一条具体分数的记录，当事务A修改结束值后，再次查询发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

4.1.4、不可重复读与幻读的区别

不可重复读是由对某一行数据的修改引起的，侧重于对表中已有数据的修改(update)；幻读是增加或者删除了某行引起的，重于对往表中新插入或者删除一条记录（insert/delete）。因此，解决不可重复读的问题通常只需对某一行加锁，解决幻读需要对整张表加锁。

4.2、隔离级别

了解了事务中存在的并发问题之后，再来看下事务的隔离级别。在SQL标准定义了4种隔离级别，分别如下：

4.2.1、读未提交（Read Uncommitted）

事务中的修改，即使没有提交，对其他事务也是可见的。换句话说，在一个事务里面，能够读取到其他事务尚未提交的数据，未提交的数据称为脏数据，这种情况就叫做脏读。

读未提交的隔离级别最低，存在脏读问题，相当于啥也没干，事务之间没有隔离，不能解决什么问题。而且效率并不比其他级别好太多，因此实际应用非常少。

4.2.2、读已提交（Read Committed）

一个事务开始时，只能看到其他已经提交的事务所做的修改，对其他事务未提交的修改是看不见的。换言之，一个事务所做的修改在最终提交之前，对其他事务是不可见的。这就解决了前面的脏读问题，它满足隔离性简单的定义，是多数数据库默认的隔离级别（但不是MySQL的默认隔离级别）。

但是，读已提交不能解决不可重复读的问题。也就是说，在一个事务A中，首先读取了一条数据，然后事务B对这条数据进行了修改，并且进行了提交，然后在事务A中再次读取此数据时，就会发现与之前读取的值不同，这就是不可重复读。

4.2.3、可重复读（Repeatable Read）

解决了脏读和不可重复读问题，是MySQL的默认隔离级别。在可重复读隔离级别中，能够保证在同一个事务中，多次读取同一行记录时，读取到的结果是相同的。但是，如果在一个事务中，多次读取的不是某一行记录的值，而是总的行数之类的数据，就有可能出现幻读问题。比如事务A首先读取了表中总的行数，然后事务B往表中新插入或者删除了一条数据并进行了事务提交，然后在事务A中再次读取表中总的行数，就会发现与之前读取的结果不同，这种情况就叫做幻读。

4.2.4、串行化（Serializable）

强制事务的串行执行，避免了包括幻读在内的一切并发问题，但是效率太低。

事务的隔离级别与对应存在的并发问题总结如下（MySQL）：

事务隔离级别	存在脏读问题	存在不可重复读问题	存在幻读问题
未提交读（read-uncommitted）	是	是	是
不可重复读（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否