RR隔离级别（可重复读数据库默认的隔离级别）
1：如果是符合readview条件，那就直接取最新数:2：如果是其中某个undolog的 readview条件，那么就去读取那个版本的旧数据
innodb
索引
读已提交
间隙锁
是
事物A去查询数据，这个事物B去修改数据，提交了，那么事物A如果再去查询数据，那么2次查询出来的结果就不一致。
undolog 存储 每个需要回滚的记录表
锁定大于age>10整个范围
age没索引
脏读，不可重复读，幻读都会出现
不加for update
mysql的事物隔离级别
全部都解决了
整表查询锁住全表
mysql的读
底层结构B+树
默认就是快照读，不会有间隙锁，无法解决幻读
事物的几种问题
加for update情况，当前读
读未提交
可重复读，同时也是数据库默认级别，简称RR
快照读某条记录
获取当前记录的事物id
事物最小id
事物A去查询数据的时候，突然事物B去修改事物，这个时候事物B还没提交，但是事物A已经查询出来了，那么这个时候B如果出现了回滚操作，那么事物A读取的时候就是错的
readview 快照读的结构
解决脏读，不可重复读，没解决幻读
执行一个select语句比如 select * from student where age 10 for update
myisan
当前事物小于最小的事物id
事物的长度
事物最大id
判断当前事物是否在事物链表中
版本回滚记录表
底层结构B树
解决幻读办法
否
事物A去查询数据，突然有事物B插入正好是和事物A查询有关的数据，这个时候事物A如果再次查询，发现2边的前后查询结果不一致了
脏读
串行读
幻读
对比B数，1：它的优点是范围查询快2：B数只有表锁3：由于B+数叶子节点存数据，所以相同页面级情况下，明显B+数能存的数据更多。
索引常见问题：1：为什么重复列太多的不建议建立索引？主要是由于我们去查找非聚集索引的时候，主要是你表的那个字段重复数据太多的话，我们通过回表去查询的主键对应的列数据的话，要查询很多次，自然就很消耗性能，基本起不到优化查询的速度。2：数据量太大的情况下我们建立索引还能去优化查询速度吗，索引的瓶颈是什么？其实当数据量足够大的时候，我们加索引去查询的时候也会很慢，主要是其实我们性能的瓶颈在于IO，当我们建立某个索引树的时候，对应的数据量也很大，那么其实我们io的次数也很多，那么优化起来也就不明显了。3：为什么索引要遵循最左原则呢？我们索引的建立其实是有顺序的，比如abc这种联合索引，我们a是有顺序的，B是依赖A的顺序，如果我们只去用B其实是无顺序的。
mysql 引擎
解决可重复读办法
不加for update情况下 快照读
MVCC流程图
解决脏读，其余的都没解决
事物列表
age有索引
redolong 数据最新的值
innoDB引擎在每行增加了3个字段 ，唯一行号，记录事物的id，以及回滚的版本号
不可重复读
继续去udolong日志的版本号去需找下一个事物id
MVCC
当前事物是否大于
当前的事物id
