MySQL事务隔离级别验证

一：完成ReadView的验证
1.创建表结构

2.查询出的初始化值

二：验证RC(读已提交)的ReadView功能
1.设置三个会话窗口的隔离级别

步骤

先全部会话窗口同时开启事务，会话一执行更新操作，会话二在之后执行更新操作

由于前面的事务未提交，对于会话三的窗口，执行select创建的ReadView的事务在活跃的事务范围内，对于其他会话的数据不可见，查询出来还是原来的数据

这时，会话一执行提交事务，然后会话三在执行select创建的ReadView的最小活跃事务id比会话一的事务id大，表示会话一的数据对会话三的查询可见

最后，会话二执行提交事务，同会话一的情况一致，会话三可以查询到会话二的数据，然后会话三也提交事务

RC结论：
每次执行select的操作都会创建一个新的ReadView去记录当前活跃的事务id，通过版本链表判断是否对当前事务可见

三：验证RR(可重复读)的可见性
所有会话窗口设置可重复读隔离级别

所有会话窗口执行开启事务，然后会话一执行更新操作，接着会话二执行更新操作，接着会话三执行查询，由于可重复读select创建ReadView只会一次，所以当前的活跃事务表包含这个三个事务，所以会话三查不到数据

然后会话一执行commit提交事务，会话三执行查询操作，由于可重复读的ReadView只创建一次，对于会话一的事务id还是在会话三的活跃事务表中，所以对于会话三还是不可见

之后会话二执行提交事务，同理会话一的情况，对于会话三还是不可见

最后，会话三提交事务，执行查询时会创建一个新的ReadView，所以对于之前修改的数据可见

RR结论：
在事务开始后第一次读取数据时生成一个ReadView。对于使用RR 隔离级别的事务来说，只会在第一次
执行查询语句时生成一个ReadView ，之后的查询就不会重复生成了。我们还是用例子看一下是什么效
果。

MVCC：多版本并发控制，用来对数据库数据进行并发访问，实现事务；核心是读不加锁，读写不冲突
MVCC是依赖于Undo日志和ReadView

Undo日志保存着记录修改前的快照；对于insert和update操作记录，只对当前的事务起效，对于其他事务不可见，而update操作记录会生成一个undo日志的版本链表

ReadView是一张存储事务id记录表

m_low_limit_id：事务id下限，表示当前系统中活跃的读写事务中最小的事务id，m_ids事务列表
中的最小事务id
m_ids：表示在生成ReadView时，当前系统中活跃的读写事务id列表
m_up_limit_id：事务id上限，表示生成ReadView时，系统中应该分配给下一个事务的id值
m_creator_trx_id：表示生成该ReadView的事务的事务id

可见性：
开启事务执行第一次查询时，首先生成ReadView，然后依据Undo日志和ReadView按照判断可见性，
按照下边步骤判断记录的版本链的某个版本是否可见。

循环判断规则如下：

1.如果被访问版本的trx_id 属性值，小于ReadView中的事务下限id，表明生成该版本的事务在生
成ReadView 前已经提交，所以该版本可以被当前事务访问。
2.如果被访问版本的trx_id 属性值，等于ReadView中的m_creator_trx_id ，可以被访问。
3.如果被访问版本的trx_id 属性值，大于等于ReadView中的事务上限id，在生成ReadView 后才产
生的数据，所以该版本不可以被当前事务访问。
4.如果被访问版本的trx_id 属性值，在事务下限id和事务上限id之间，那就需要判断是不是在
m_ids 列表中。
4.1如果在，说明创建ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问；
4.2如果不在，说明创建ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

循环判断Undo log中的版本链某一的版本是否对当前事务可见，如果循环到最后一个版本也不可见的
话，那么就意味着该条记录对该事务不可见，查询结果就不包含该记录。

索引
是为了提高高效的查询效率，通过空间换时间的理论的一种数据结构
优点：提高查询效率，降低IO操作，降低排序操作和CPU的消耗
缺点：耗费磁盘空间，降低更新表的效率。

索引的分类：
主键索引：索引列中的值必须是唯一的不允许有空值
唯一索引：索引列中的值必须是唯一的，但是允许为空值
普通索引：MySQL中基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值
全文索引：只能在文本类型CHAR，VARCHAR，TEXT类型字段上创建全文索引
空间索引：MySQL在5.7之后的版本支持了空间索引，而且支持OpenGIS几何数据模型
前缀索引：在文本类型如CHAR，VARCHAR，TEXT类列上创建索引时，可以指定索引列的长度，
但是数值类型不能指定
组合索引：由多个字段联合的普通索引

InnoDB创建索引的具体规则如下：
1.在表上定义主键PRIMARY KEY，InnoDB将主键索引用作聚簇索引。
2.如果表没有定义主键，InnoDB会选择第一个不为NULL的唯一索引列用作聚簇索引。
3.如果以上两个都没有，InnoDB 会使用一个6 字节长整型的隐式字段 ROWID字段构建聚簇索引。该
ROWID字段会在插入新行时自动递增。

索引的注意事项：
1.表记录很少不需创建索引
2.一个表的索引个数不能过多
3.频繁更新的字段不建议作为索引
4.区分度低的字段，不建议建索引
5.在InnoDB存储引擎中，主键索引建议使用自增的长整型，避免使用很长的字段
6.不建议用无序的值作为索引
7.尽量创建组合索引，而不是单列索引
8.不要在索引上做计算
9.索引上不要使用不等，不要判断null
10.索引字段字符串要加单引号
11.索引匹配要满足最左匹配原则

如何知道 SQL 是否用到了索引
通过Explain执行计划中的possible_key 与 key

索引的原理：
hash数据结构：key-value适合做的缓存
二叉查找树：极端情况需要做全表扫描，而且对磁盘io不友好
红黑树：不支持范围查询，索引占用空间大
B树：空间占用大，无法快速查询范围
B+树：继承B树的优点，优化了空间的占用和范围查询，非叶子节点不保存数据