脏读，不可重复读，幻读是如何发生的？
参考:https://blog.csdn.net/zzti_erlie/article/details/88080822
介绍
要聊事务，不可避免的要提到数据库事务的四大特性
原子性（Atomic）
一致性（Consistency）
隔离性（Isolation）
持久性（Durability）
今天只聊隔离性，其他的比较好理解，建议看推荐阅读中关于事务的讲解。
先放一个表格，看看4个隔离级别会出现的各种问题，网上的解释一大堆。看完后还是一脸蒙蔽，感觉懂了，又好像没懂。因为没有具体的演示例子，索性自己尝试复现这几个问题，果然理解的清清楚楚。
√ 为会发生，×为不会发生, ×√ 大部分会避免
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| read uncommitted（未提交读） | √ | √ | √ |
| read committed（提交读） | × | ×√ | √ |
| repeatable read（可重复读） | × | × | × |
| serializable （可串行化） | × | × | × |
先看MySQL版本，5.5.61，下文的所有实验在这个版本上都能浮现
`select version()`
* 1
MySQL查看隔离级别
`SELECT @@tx_isolation`
* 1
MySQL在会话层面设置隔离级别
`set session transaction isolation level 隔离级别`
* 1
开启事务
`start transaction`
* 1
提交事务
`commit`
* 1
回滚事务
`rollback`
* 1
建立如下表
``CREATE TABLE `account` (
`id` int(2) NOT NULL AUTO_INCREMENT,
`name` varchar(10) DEFAULT NULL,
`balance` int(3) DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4;``
* 1
* 2
* 3
* 4
* 5
* 6
用Navicat（其他工具也行）开2个查询的tab页，表示2个会话
在2个Tab页面分别执行如下语句
`SELECT @@tx_isolation`
* 1
输入都是REPEATABLE-READ，表明MySQL默认隔离级别为REPEATABLE-READ（可重复）读。
脏读
表中的数据如下，设置隔离级别为未提交读
按照时间在2个Tab页依次执行如下命令
| 时间 | 客户端A（Tab A） | 客户端B（Tab B） |
|---|---|---|
| T1 | set session transaction isolation level read uncommitted; | |
| start transaction;（开启事务） | ||
| update account set balance = balance + 1000 where id = 1; | ||
| select * from account where id = 1; | ||
| 设置为未提交读，给张三账号+1000，输出为2000 | ||
| T2 | set session transaction isolation level read uncommitted; | |
| start transaction; | ||
| select * from account where id = 1; | ||
| 查询余额输出为2000 | ||
| T3 | rollback | |
| T4 | commit | |
| T5 | select * from account where id = 1; | |
| 查询余额输出为1000 |
举个例子概述一下这个过程，财务给张三发了1000元的工资，然后张三查询自己的账户，果然多了1000元，变成了2000元，结果财务操作过程有误，事务回滚。当张三再查账户时，却发现账户只有1000元。
脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。
再举一个严重的例子，证明一下危害
表中的数据如下
| 时间 | 客户端A（Tab A） | 客户端B（Tab B） |
|---|---|---|
| T1 | set session transaction isolation level read uncommitted; | |
| start transaction; | ||
| update account set balance = balance - 1000 where id = 1; | ||
| update account set balance = balance + 1000 where id = 2; | ||
| T2 | set session transaction isolation level read uncommitted; | |
| start transaction; | ||
| select balance from account where id = 2; | ||
| update account set balance = balance - 1000 where id = 2; | ||
| 更新语句被阻塞 | ||
| T3 | rollback | |
| T4 | commit |
执行完成，数据库中的数据如下
| 时间 | 解释 |
|---|---|
| T1 | 1给2转1000 |
| T2 | 2的余额够1000元，购买1000元的东西，更新语句被阻塞 |
| T3 | 1回滚，1的余额变成1000，2的余额变成0 |
| T4 | 2成功扣款，余额0-1000=-1000 |
现在好了，银行无缘无故损失1000元。
不可重复读
表中的数据如下，设置隔离级别为提交读
| 时间 | 客户端A（Tab A） | 客户端B（Tab B） |
|---|---|---|
| T1 | set session transaction isolation level read committed; | |
| start transaction; | ||
| select * from account where id = 2; | ||
| 查询余额输出为0 | ||
| T2 | set session transaction isolation level read committed; | |
| start transaction; | ||
| update account set balance = balance + 1000 where id = 2; | ||
| select * from account where id = 2; | ||
| commit; | ||
| 查询余额输出1000 | ||
| T3 | select * from account where id = 2; | |
| commit; | ||
| 查询余额输出1000 |
不可重复读是指在事务1内，读取了一个数据，事务1还没有结束时，事务2也访问了这个数据，修改了这个数据，并提交。紧接着，事务1又读这个数据。由于事务2的修改，那么事务1两次读到的的数据可能是不一样的，因此称为是不可重复读。
当然你可以在T2时间段客户端B修改完id=2的账户余额但没有commit的时候，在客户端A查询id=2的账户余额，发现账户余额为0，可以证明提交读这个隔离级别不会发生脏读。
现在用上面的例子看一下可重复读是个什么过程？
表中的数据如下，设置隔离级别为可重复读
| 时间 | 客户端A（Tab A） | 客户端B（Tab B） |
|---|---|---|
| T1 | set session transaction isolation level repeatable read; | |
| start transaction; | ||
| select * from account where id = 2; | ||
| 查询余额输出为0 | ||
| T2 | set session transaction isolation level repeatable read; | |
| start transaction; | ||
| update account set balance = balance + 1000 where id = 2; | ||
| select * from account where id = 2; | ||
| commit; | ||
| 查询余额输出1000 | ||
| T3 | select * from account where id = 2; | |
| commit; | ||
| 查询余额输出0 |
仔细看这个例子和上面的例子在T3时间段的输出，理解了什么叫可重复读了吧？当我们将当前会话的隔离级别设置为可重复读的时候，当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。
但是在可重复读的隔离级别上，会产生幻读的问题。
幻读
表中的数据如下，设置隔离级别为可重复读
先上一段《高性能MySQL》对于幻读的解释
所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。InnoDB存储引擎通过多版本并发控制（MVCC）解决了幻读的问题。
用大白话解释一下，就是事务1查询id<10的记录时，返回了2条记录，接着事务2插入了一条id为3的记录，并提交。接着事务1查询id<10的记录时，返回了3条记录，说好的可重复读呢？结果却多了一条数据。
MySQL通过MVCC解决了这种情况下的幻读，我们可以验证一下
| 时间 | 客户端A（Tab A） | 客户端B（Tab B） |
|---|---|---|
| T1 | set session transaction isolation level repeatable read; | |
| start transaction; | ||
| select count(*) from account where id <= 10; | ||
| 输出2 | ||
| T2 | set session transaction isolation level repeatable read; | |
| start transaction; | ||
| insert into account (id, name, balance) values (3, “王五”, 0); | ||
| select count(*) from account where id <= 10; | ||
| commit; | ||
| 输出3 | ||
| T3 | select count(*) from account where id <= 10; | |
| commit; | ||
| 输出2 |
这种情况下的幻读被解决了，我再举一个例子
表中的数据如下
| 时间 | 客户端A（Tab A） | 客户端B（Tab B） |
|---|---|---|
| T1 | set session transaction isolation level repeatable read; | |
| start transaction; | ||
| select count(*) from account where id = 3; | ||
| 输出为0 | ||
| T2 | set session transaction isolation level repeatable read; | |
| start transaction; | ||
| insert into account (id, name, balance) values (3, “王五”, 0); | ||
| commit; | ||
| T3 | insert into account (id, name, balance) values (3, “王五”, 0); | |
| 主键重复，插入失败 | ||
| T4 | select count(*) from account where id = 3; | |
| 输出为0 | ||
| T5 | rollback; |
select 某记录是否存在，不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，这个就有问题了。
很多人容易搞混不可重复读和幻读，确实这两者有些相似。但不可重复读重点在于update和delete，而幻读的重点在于insert。
总的来说幻读就是事务A对数据进行操作，事务B还是可以用insert插入数据的，因为使用的是行锁，这样导致的各种奇葩问题就是幻读。
当隔离级别设置为可串行化，强制事务串行执行，避免了前面说的幻读的问题。
