数据库事务的四大特征和隔离级别

事务的四大特征：

1. 原子性：是不可分割的最小操作单位，要么同时成功，要么同时失败

2. 持久性：当事务提交或回滚后，数据库会持久化的保存数据

3. 隔离性：多个事务之间，相互独立

4. 一致性：事务操作前后，数据总量不变

事务的隔离级别

概念：
多个事务之间隔离的，相互独立的。但是如果多个事务操作同一批数据，则会引发一些问题，设置不同的隔离级别就可以解决这些问题。

存在问题：

• 脏读：一个事务，读取到另一个事务中没有提交的数据

• 不可重复读(虚读)：在同一个事务中，两次读取到的数据不一样。

• 幻读：一个事务操作(DML)数据表中所有记录，另一个事务添加了一条数据，则第一个事务查询不到自己的修改。

隔离级别：

1. read uncommitted：读未提交
   • 产生的问题：脏读、不可重复读、幻读
2. read committed：读已提交 （Oracle）
   • 产生的问题：不可重复读、幻读
3. repeatable read：可重复读 （MySQL默认）
   • 产生的问题：幻读
4. serializable：串行化
   • 可以解决所有的问题

• 注意：隔离级别从小到大安全性越来越高，但是效率越来越低

  数据库隔离级别查询：

• select @@tx_isolation;

  数据库设置隔离级别：

• set global transaction isolation level 级别字符串;

隔离级别详细概述：

准备工作：

首先创建一个表 account，创建表的过程略过（表的存储引擎设置为 InnoDB）。表的结构如下：

然后往表中插入两条数据，插入后结果如下：

为了说明问题，我们打开两个控制台分别进行登录来模拟两个用户（暂且成为用户 A 和用户 B 吧），并设置当前 MySQL 会话的事务隔离级别。

1 read uncommitted（读取未提交数据）

具体用户 A 的操作如下：

set session transaction isolation level read uncommitted；start transaction;
select * from  account;

结果如下：

用户 B 的操作如下：

set session transaction isolation level read uncommitted；
start transaction;update account set account=account+200 where id = 1;

随后我们在 A 用户中查询数据，结果如***意，此时B并未提交数据）：

总结：

我们将事务隔离级别设置为 read uncommitted，即便是事务没有 commit，但是我们仍然能读到未提交的数据，这是所有隔离级别中最低的一种。

那么这么做有什么问题吗？（脏读）

那就是我们在一个事务中可以随随便便读取到其他事务未提交的数据，这还是比较麻烦的，叫脏读。

实际上我们的数据改变了吗？

答案是否定的，因为只有事务 commit 后才会更新到数据库，如果此时B的操作产生异常回滚了呢？这种操作会带来极大的安全隐患，几乎不使用。

2 read committed（读已提交）— 大多数数据库默认的隔离级别(Oracle)

同样的办法，我们将用户 B 所在的会话当前事务隔离级别设置为 read commited。

在用户 A 所在的会话中我们执行下面操作：

update account set account=account-200 where id=1;

我们将 id=1 的用户 account 减 200。然后查询，发现 id=1 的用户 account 变为 800。

在 B 用户所在的会话中查询：

select * from account；

结果如下：

我们会发现数据并没有变，还是 1000。

接着在会话 A 中我们将事务提交：

commit;

在会话 B 中查询结果如下：

结论二：

当我们将当前会话的隔离级别设置为 read committed 的时候，当前会话只能读取到其他事务提交的数据，未提交的数据读不到。（解决了脏读问题）

那么这么做有什么问题吗？ 不可重复读和幻读问题

那就是我们在会话 B 同一个事务中，读取到两次不同的结果。这就造成了不可重复读，就是两次读取的结果不同。这种现象叫不可重复读。

3 repeatable read（可重复读）—MySQL 默认的隔离级别

现在有个需求，就是老板说在同一个事务中查询结果必须保持一致，你会怎么做？
在会话 B 中我们当前事务隔离级别为 repeatable read。具体操作如下：

set session transaction isolation level repeatable read;
start transaction;

接着在会话 B 中查询数据：

我们在 A 用户所在会话中为表 account 添加一条数据：

insert into account(id,account) value(3,1000);
commit;

然后我们查询看数据插入是否成功：

回到 B 用户所在的会话，我们查询结果：

用户 B 在他所在的会话中想插入一条新数据 id=3，value=1000。来我们操作下：

什么？竟然插不进去，说我数据重复？

用户 B 当然不服啊，因为查询到数据只有两条啊，为什么插入 id=3 说我数据重复了呢？

我再看一遍，莫非我眼花了？（幻读）

试想一下，在实际中用户 A 和用户 B 肯定是相互隔离的，彼此不知道操作什么。用户 B 碰到这种现象，肯定会打电话投诉啊，明明不存在的数据，插入却说主键 id=3 数据重复了。

说明：

当我们将当前会话的隔离级别设置为 repeatable read 的时候，当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。

有什么问题吗？

管他呢，老板的要求满足了。要一个事务中读取的数据一致（可重复读）。我只能这么做啊。数据已经发生改变，但是我还是要保持一致。但是，出现了用户 B 面对的问题，这种现象叫幻读（就像产生幻觉一样）。

4 serializable（串行化）

同样，我们将用户 B 所在的会话的事务隔离级别设置为 serializable 并开启事务。

set session transaction isolation level serializable;
start transaction;

在用户 B 所在的会话中我们执行下面操作：

select * from account;

结果如下：

那我们这个时候在用户 A 所在的会话中写数据呢？

我们发现用户 A 所在的会话被阻塞了，如果超时（这个时间可以进行配置），会出现 Lock wait time out 提示：

如果在等待期间我们用户 B 所在的会话事务提交，那么用户 A 所在的事务的写操作将提示操作成功。

说明：

当我们将当前会话的隔离级别设置为 serializable 的时候，其他会话对该表的写操作将被挂起（表锁，具体的锁模块可以看我的另一篇博客）。可以看到，这是隔离级别中最严格的，但是这样做势必对性能造成影响。所以在实际的选用上，我们要根据当前具体的情况选用合适的（现在都要求高并发了，怎么可能用）。

（彩蛋）面试场景：

• 面试官：“讲讲mysql有几个事务隔离级别？”

• 你：“读未提交，读已提交，可重复读，串行化四个！默认是可重复读”

• 面试官：“为什么mysql选可重复读作为默认的隔离级别？”

• 你：这是MySQL的历史遗留问题，因为在老版MySQL（5.0以前）中，read committed（读已提交）在主从同步时有bug，具体就是会导致主从不一致性的问题 ，

  原因其实很简单，就是在master上执行的顺序为先删后插！而此时binlog为STATEMENT格式（只支持STATEMENT格式），它记录的顺序为先插后删！从(slave)同步的是binglog，因此从机执行的顺序和主机不一致！就会出现主从不一致！

• 面试官:"你们项目中选了哪个隔离级别？为什么？"

• 你：我们项目使用的read committed（读已提交）；

  1.因为这个bug在5.1之后就修复了，我们项目用的是5.7，而且读已提交的性能比可重复读并发性能更好

  2.可重复读在主从同步时存在一个间隙锁，会锁住查询事务的范围，防止其他事务在这个范围中插入数据， 而在读已提交隔离级别下，不存在间隙锁，其他事务是可以插入数据（前者性能消耗更多，造成死锁的概率更大）

  3.在读已提交隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性