一，事务隔离级别

1.事务并发执行的一致性问题

1. 脏写：一个事务修改了另一个未提交事务修改过的数据
2. 脏读：一个事物读到了另一个未提交事务修改过的数据
3. 不可重复读：一个事物修改了另一个未提交事务读取的数据
4. 幻读：一个事物先根据某些搜索条件查询出一些记录，在该事务未提交时，另一个事务写入了一些符合搜索条件的记录

2.SQL标准中的隔离级别

舍弃一部分隔离性来换取一部分性能在这里就体现在：设立一些隔离级别，隔离级别越低，越严重的问题就越可能发生。

SQL标准中规定，针对不同的隔离级别，并发事务可以发生不同严重程度的问题，具体情况如下：

也就是说：

• READ UNCOMMITTED隔离级别下，可能发生脏读、不可重复读和幻读问题。
• READ COMMITTED隔离级别下，可能发生不可重复读和幻读问题，但是不可以发生脏读问题。
• REPEATABLE READ隔离级别下，可能发生幻读问题，但是不可以发生脏读和不可重复读的问题。
• SERIALIZABLE隔离级别下，各种问题都不可以发生。

  二，一致性非锁读

  1.概念

MVCC是一种并发控制的方法，mysql的innodb就是基于MVCC实现对数据库的并发访问。
在innodb引擎中指的就是在读已提交和可重复读这两种隔离级别下的事务对于select操作会访问版本链中的记录过程。别的事务可以修改这条记录，修改会记录在版本链中，select的时候可以直接去版本链中拿记录，这就可以实现读写的同时执行，提高效率。

2.版本链

在Innodb的聚簇索引也就是主键索引中有两个隐藏列：

trx_id:存储每次对某条聚簇索引记录进行修改的时候的事务id。
roll_pointer：每次对哪条聚簇索引记录有修改的时候，都会把老版本写入到undo日志中。这个roll_pointer就是一个指针，他指向这条聚簇索引记录的上一个版本的位置，通过他来获取上一个版本的记录（insert操作在undo日志中没有这个属性，因为他没有老版本）。

3.ReadView

读已提交和可重复读的区别就在于他们生成ReadView的策略不同。
ReadView中主要就是有个列表来存储我们系统中当前活跃着的读写事务，也就是begin了还未提交的事务。通过这个列表来判断记录的某个版本是否对当前事务可见。
假设当前事务列表里面的事务id为[80,100].

1. 
   如果你要访问的记录版本的事务id为50，比80还小，那说明这个事务在之前就已经提交了，所以对于当前事务是可以访问的。
2. 如果你要访问的记录版本的事务id为90，发现此事务在列表id的最大值和最小值之间，那就判断一下是否在列表内，如果在那就说明此事务还未提交，所以版本不能被访问。如果不再，说明事务已经提交，所以版本可以被访问。
3. 如果你要访问的记录版本的事务id为110，那比事务列表最大id100都大，那说明这个版本是在ReadView生成之后才发生的，所以不能被访问。

这些记录都是去版本链里面找的，先找最近记录，如果最近这一条事务id不符合条件，不可见的话，再去找上一个版本在比较当前事务的id和这个版本的事务id看能不能访问，以此类推直到返回可见的版本或者结束。

case：在读已提交隔离级别下：
比如此时有一个事务id为100的事务，修改了name，使得name等于小明2，但是事务还没提交。则此时的版本链是：

那此时另一个事务发起了select 语句要查询id为1的记录，那此时生成的ReadView 列表只有[100]。那就去版本链去找了，首先肯定找最近的一条，发现trx_id是100,也就是name为小明2的那条记录，发现在列表内，所以不能访问。
这时候就通过指针继续找下一条，name为小明1的记录，发现trx_id是60，小于列表中的最小id,所以可以访问，直接访问结果为小明1。
那这时候我们把事务id为100的事务提交了，并且新建了一个事务id为110也修改id为1的记录，并且不提交事务。这时候的版本链是：

这时候之前那个select事务又执行了一次查询,要查询id为1的记录。
这个时候关键的地方来了
如果你是已提交读隔离级别，这时候你会重新生成一个ReadView，那你的活动事务列表中的值就变了，变成了[110]。
按照上的说法，你去版本链通过trx_id对比查找到合适的结果就是小明2。
如果你是可重复读隔离级别，这时候你的ReadView还是第一次select时候生成的ReadView,也就是列表的值还是[100]。所以select的结果是小明1。所以第二次select结果和第一次一样，所以叫可重复读！
也就是说已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView,而可重复读隔离级别则在第一次读的时候生成一个ReadView，之后的读都复用之前的ReadView。
这就是Mysql的MVCC,通过版本链，实现多版本，可并发读-写，写-读。通过ReadView生成策略的不同实现不同的隔离级别。

三，purge

1. insert undo 日志在事务提交之后就可以释放掉了，而update undo 日志由于还需要支持MVCC，因此不能立即删除。
2. 为了支持MVCC，delete mark 操作仅仅是在记录上打一个删除标记，并没有真正将记录删除。

为了节约存储空间，我们应该在合适的时机把 update undo log 以及仅仅标记为delete mark的记录彻底删除，这个删除操作就成为purge。关键在于：这个合适的时机。

update undo日志和被标记为删除的记录只是为了支持MCC而存在的，只要系统中最早产生的那个ReadView不再访问它们，它们的使命就结束了，就可以丢进历史的垃圾堆里了。一个 ReadView在什么时候才肯定不会访问某个事务执行过程中产生的undo日志呢?其实，只要我们能保证生成ReadView时某个事务已经提交，那么该 ReadView肯定就不需要访问该事务运行过程中产生的undo日志了(因为该事务所改动的记录的最新版本均对该ReadView可见)。

1. 在一个事务提交时，会为这个事务生成一个名为事务no的值，该值用来表示事物提交的顺序，先提交的事务的事务no值小，后提交的大。
2. 一个ReadView结构其实还包含一个事务no的属性。在生成一个ReadView的时候，会把比当前系统中最大的事务no值还大1的值赋值给这个属性。

InnoDB还把当前系统中所有的ReadView按照创建时间连成了一个链表。当执行purge操作时(这个purge操作是在专门的后台线程中执行的)，就把系统中最早生成的ReadView给取出来。如果当前系统中不存在ReadView，就现场创建一个(新创建的这个ReadView的事务no值肯定比当前已经提交的事务的事务 no值大)。然后从各个回滚段的History 链表中取出事务no值较小的各组undo日志。如果一组undo日志的事务 no 值小于当前系统最早生成的ReadView的事务no属性值，就意味着该组undo日志没有用了，就会从History链表中移除，并且释放掉它们占用的存储空间。 如果该组undo日志包含因 delete mark 操作而产生的undo日志(TRX_UNDO_DEL_MARKS 属性值为1)，那么也需要将对应的标记为删除的记录给彻底删除。

注意：当前系统中最早生成的ReadView决定了purge操作中可以清理哪些update undo log以及 delete mark log。如果某个事物使用可重复读的隔离级别，那么这个事务会一直复用最初产生的ReadView。假如这个事务运行了很久，一直没有提交，那么最早生成的ReadView一直不释放，系统中的update undo log以及 delete mark log会越来越多，表空间文件越来越大，一条记录的版本链越来越长，从而影响系统性能。

四，一致性非锁读的演示

会话1：

#前置准备
create database es_lock;
use es_lock;
create table parent (id int ,name varchar(20) not null);
insert into parent(id,name)values (1,'aaa'),(2,'bbb'),(3,'ccc'),(4,'ddd'),(5,'eee'),(6,'fff'),(7,'ggg');
# 开始
begin;
select * from parent where id =1;
# 1
select * from parent where id =1;
# 3 不同隔离级别下的结果：
select * from parent where id =1;
# 读已提交：null
# 可重复读：1条记录
commit ;

会话2：

use es_lock;
# 开始
begin ;
update parent set id =3 where id =1;
# 2
commit ;