简述事务的四大特性（事务的四大特性和隔离级别）

0. 说明

前两天有件事遇到了事务的特性和隔离级别的问题，（什么事，你懂的）。今天就总结下这两个内容，主要参考的是《高性能MySQL》这本巨著。

1. 事务的四大特性

事务的四大特性（ACID），顾名思义，就是4个特性，先看下图：

事务的四大特性

下面我们具体看下在书中四大特性的概念。

1.1 原子性

一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。

1.2 一致性

数据库总是从一个一致性的状态转换到另外一个一致性的状态。在著名的转账的例子中，一致性确保了无论中间的那条语句执行时系统崩溃，或者其他原因导致语句执行失败，支票账户中也不会损失，因为事务最终没有被提交，所以事务中所做的修改也不会被保存在数据库中。

1.3 隔离性

通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。在著名的转账的例子中，当事务没有提交的时候，转账的语句执行了，此时有另外一个账户汇总程序开始运行，则其看到的支票账户的余额并没有改变。后面我们讨论隔离级别的时候，会发现为什么我们要说“通常来说”是不可见的。

1.4 持久性

一旦事务提交，则其所做的修改就会被永远保存到数据库中。此时即便是系统崩溃，修改的数据也不会丢失。持久性是个有点模糊的概念，因为实际上持久性也分很多不同的级别。有些持久性策略能够提供非常强的安全保障，而有些则未必。而且不能有能做到100%的持久性保证的策略（如果数据库本身就能做到真正的持久性，那么备份又怎么能增加持久性呢？）。这个在上面说到的这本巨著中会详细的讨论MySQL中持久性的真正含义。

2. 事务的隔离级别

事务的隔离级别主要是讲事务的隔离性。主要是不同事务之间的可见性问题，还是先看下图：

事务的隔离级别

下面主要看下书中讲的事务的四个隔离级别。

2.1 未提交读

在Read Uncommitted级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说，Read Uncommitted不会被其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。

2.2 提交读

大多数数据库系统的默认隔离级别是Read Committed(但MySQL不是)。Read Committed满足前面提到的隔离性的简单定义：一个事务开始时，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始知道提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读（nonrepeatable read），因为两次执行同样的查询，可能会得到不一样的结果。

2.3 可重复读

Repeatable Read解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（Phantom Read）的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row）。InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC,Multiversion Concurrency Control）解决了幻读的问题。**可重复读是MySQL的默认事务隔离级别**。

2.4 可串行化

Serializable是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，Serializable会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。

3. 总结

对于事务的四大特性，没什么说的，就是一些保证数据一致性的特点。这些特点也会适用于现在流行的分布式系统中的分布式事务中。事务的隔离级别是一个比较难懂的问题，因为可能会导致脏读，幻读，不可重复读，或者性能为题，这个我们后面有机会再出文章解释，需要的可以先关注下本公众号。希望本文能对各位看客理解数据库事务有所帮助。

求评论、点赞、关注 转发。

限于笔者知识有限，如果不足之处请帮忙指正，不喜勿喷！

您的支持是我不懈努力的动力，请读者多支持下！

更多文章，请关注微信公众号 CS_Toper之路，或者头条号 CSToper。