事务和事务的隔离级别原理

事务与并发控制

最新推荐文章于 2025-09-12 15:59:36 发布

原创最新推荐文章于 2025-09-12 15:59:36 发布 · 664 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#事务

mysql 专栏收录该内容

9 篇文章

订阅专栏

本文深入解析数据库事务的概念，包括事务的ACID特性、并发带来的数据一致性问题，以及四种隔离级别如何通过MVCC和Next-key Lock机制解决幻读等问题。

原子性（atomicity）
事务被视为一个不可分割的最小工作单元，要么全成功，要么全失败。
一致性（consistency）
事务的一致性体现在使数据库从一个一致性状态到另个一致性状态。简单理解就是，不管事务执行的增删查改什么组合操作，在事务执行后保持数据一致性。这个一致性是指在当前状态对所有的事务来说读取的结果总是相同的。
隔离性（isolation）
隔离性是指事务在提交前所作的操作，对其他事务是不可见的。
持久性（durability）
只要事务提交成功，其所作的修改就会永久保存在数据库中。就算数据库发生崩溃，事务操作的结果也不会丢失。使用重做日志来保证持久性。

在没有并发的情况下，事务的隔离性天然满足，事务只要满足原子性，就能保证数据的一致性。在并发的情况下，事务需要满足隔离性和原子性来保证数据的一致性。持久性是为了应对数据库崩溃的情况。

并发带来的数据一致性问题

1.丢失修改
通俗一点说就是，多事务同时操作同一数据，事务1修改的结果在提交前被其他事物覆盖，最终导致了事务1的修改结果丢失的情况。
2.脏读
多事务同时操作同一数据时，事务1的进行修改，但是在提交前进行了回滚操作。但是在回滚之前，其他事务读到了事务1修改后的结果，造成其他事务读取了无用的数据，这种状况称之为脏读。
3.不可重复读
同一事务两次读取的结果不一致的情况。这是因为同一事务的两次读之间其他事务对数据进行了修改。
4.幻读（虚读）
同一个事务读取某范围的数据，两次结果不一致。两次读之间其他事务对此范围的数据进行了插入数据操作。

事务的隔离级别的理解

四个隔离级别

1.未提交读（READ UNCOMMIT）
事务中的修改，即使没提交，其他事务也可见。这样会产生很多问题，比如说脏读，丢失修改，不可重复读，幻读等。在并发环境中这种隔离级别几乎不被采用。
2.提交读（READ COMMIT）
事务中的修改，再提交成功后其他事务才可见，提交成功前其他事物不可见。这样避免了脏读，但是依然存在不可重复读的状况，因为可能其他事务在第二次读取之前完成了修改并提交成功。
3.可重复读（REPEATABLE READ）（mysql默认隔离级别）
保证了两次读取的数据结果相同，避免了不可重复读的情况，但是幻读的情况依然无法解决。
4.可串行化（SERIALIZABLE）
对每一行数据都加锁，强制的将事务串行执行，这样并发行变得极差，在实际情况中也很少用。毕竟非并发的情况下，本来就是串行，需要并发提高效率时，再将事务串行执行，就违背了并行的初衷。

MVCC

多版本并发控制（Multi-Version Concurrency Control, MVCC)是Mysql的InnoDB存储引擎实现隔离级别的具体方式。用来实现隔离级别提交读和可重复读。MVCC可以看作行级锁的变种，但是它能保证大部分读操作无需加锁，减少了开销，提高了效率。MVCC在不同的存储引擎中的实现方式不一致，但大都实现了非阻塞读。

MVCC实现原理简述

MVCC在每行记录后隐藏添加了两列，一个是创建版本号和删除版本号。
创建版本号是指创建行快照时的系统版本号，每有一个事务开始，系统版本号就自动递增1。事务版本号指的是事务开始时的系统版本号。
删除版本号大于事务版本号，说明当前的事务执行有效。如果删除版本号小于事务版本号，说明在事务开始前，数据已经被删除。
MVCC读取的快照里的数据，所以快照读能较少加锁的开销。而当前读是读取的数据的最新修改，所以会加上行级锁，由于存在插入数据导致两次范围内数据不一致，所以当前读并不能解决幻读的问题。所以可以说MVCC减少了加锁的开销，提高了效率，但是每一行都增加了额外的存储空间，还需要进行检查工作和额外的维护工作。

Next-key Lock +MCVV 避免幻读

MVCC单独是解决不了幻读问题，在可重复读的隔离级别下，Next-key Lock+MVCC能解决幻读问题。
1.Next-key Lock原理
临键锁是行锁（record lock）和间隙锁(cap lock)结合实现的。不仅锁住当前的索引的行，还会用间隙锁将索引之间的范围都锁上，解决了幻读问题。