1. ReadView 案例，解释为什么 RR 和 RC 隔离级别下看到查询结果不一致
案例 01- 读已提交 RC 隔离级别下的可见性分析
开启两个回话，会话事务级别都是READ-COMMITED;
操作步骤
- 开启两个数据库会话，设置事务为提交读
- 事务2查询id=1数据，查询到的是linda
- 事务1提交事务
- 事务2查询id=1的数据，任然为Recentlyzhuzhu2
- 事务1对id=1的数据进行修改，修改为linda
- 两边开启事务，两边对查询id=1的数据，为Recentlyzhuzhu2
案例过程
结论与分析
- 提交读，解决了幻读跟不可重复读
- 但是存在幻读的问题，在事务2中同一条查询查到不同的数据
案例 02- 可重复读 RR 隔离级别下的可见性分析
开启两个回话，会话事务级别都是REPEATABLE-READ
操作步骤
- 开启两个数据库会话，设置事务为可重复读
- 事务1查询id=1数据，查询到的是zhuting2
- 事务2提交事务
- 事务1查询id=1数据，查询到的是Recentlyzhuzhu
- 事务2对id=1数据进行更新为zhuting2
- 事务2查询id=1的数据，任然为linda
- 事务1对id=1的数据进行修改，修改为zhuting,事务1再次修改Recentlyzhuzhu
- 两边开启事务
案例过程
结论与分析
- 可重复读，在本会话中查询到的数据都是一致的，解决了幻读，不可重复读，脏读，即使事务1提交了事务，在事务2的会话中还是读取到最原始的数据。
- 当事务1对数据进行update,事务2在进行update就会进行等待，修改的时候会自动加上锁，当事务1提交事务，锁自动解开，事务2完成数据的修改。
什么是索引？
要点：
1.优点是什么？
- 加快查询速度
- 降低数据库io的成本，快速的检索，减少磁盘io,提高整体性能减少磁盘磨损
- 索引对数据进行了排序，降低了数据的排序成本，降低CPU的消耗
- 索引可用于实施约束，例如唯一或主键约束，这有助于确保数据完整性并防止数据重复。
2.缺点是什么？
- 索引会占据磁盘空间
- 索引的数据结构是B+ Tree结构，索引的存在需要存储额外的数据，指针，键值对等根据索引类型的不同看存储的是键还是键值对。
- 数据表可以存在多个索引，每个索引都需要占据磁盘空间，若多个索引，那么就需要占据更多的磁盘空间
- 在对数据进行插入，删除，修改的时候，索引也需要随着数据的变化而做出修改，若索引的结构增大，占用磁盘的空间也会变大
- 索引的存在也会降低更新表的效率，加上索引的话Mysql需要保存数据，也需要维护索引文件，所以降低了效率
3.索引分类有哪些？特点是什么？
索引类型
- 单列索引
- 主键索引：primary key
- 前缀索引
- 空间索引：支持OpenGIS几何数据模型
- 全文索引:只有文本类型字段能创建fulltext，通过march(列)..against(字符串)的形式进行检索
- 唯一索引:unique
- 普通索引
- 组合索引
- 需要遵循最左匹配原则
- MYISAN索引
- 主键索引
- 索引文件存储.MYI文件中，数据文件存储在.MYD文件中
- 索引文件存储的是磁盘地址，最终数据需要根据地址到数据文件中查找
- 会将索引阶段存储在MySql缓存中，数据缓存依赖于操作系统自身缓存
- 辅助索引
- 叶子节点存储磁盘地址，但是辅助索引的键值可以重复不唯一
- 等值查询也需要按照范围查询的方式进行索引数检索数据。
- Innodb索引
- 聚簇索引，一般为主键索引，没有主键的时候会使用表里的唯一索引充当，没有唯一索引则创建隐藏列rowid构成聚簇索引
- 索引跟数据都存在.idb中
- 主键索引
- innodb中要求必须有一个主键索引
- 并且主键索引叶子简单会存储数据行
- 辅助索引
- 非主键索引列，叶子节点只会存储主键值
- 组合索引
- 满足最左匹配原则，优化器会根据组合索引优化where后边的条件
- 覆盖索引
- 当所查询的列能够在辅助索引数中全部查到，并且可以直接范围，不用会表查询
4.索引创建的原则是什么？
- 表记录很少不需要创建索引
- 频繁出现where条件，排序，分组字段的需要创建索引提高性能
- 频繁查询的列，可以创建索引
- 多表关联，两边都有的字段可以创建索引
- 一个表不能有过多的索引
- 无序的列最好别做索引
- 最好使用组合索引，多个单索引浪费空间，组合索引可以把频繁的列放在最前面
- 避免使用很长的字段做索引
5.有哪些使用索引的注意事项？
- like,or,is not null,is null ，!=,<>,字段的使用会使得索引失效
- select * 全查索引也会失效
- 使用函数，计算，类型转换索引会失效
- 字符串不加单引号索引会失效
6.如何知道 SQL 是否用到了索引？
- 通过explain语句查看
7.索引的原理是什么？「重点」
索引的底层使用了B+ Tree，数据结构，可以满足等值查询，范围查询等数据库查询的一切要求，并且B+ Tree的时间复杂度控制在O(logn)
- hash表不适合做聚合和范围查询，虽然速度很快，但是范围查询的haul需要全表扫描所有符合条件的数据
- 二叉查找树，时间复杂度根据树的高度而改变，会出现瘸腿二叉树的情况，一旦出现这种情况就会全表扫描符合条件的数据，对磁盘io不友好
- 红黑树，去除了二叉树会出现的树结构不平衡的情况，并且能够很好的划分数据的结构，但是不支持范围查询，时间复杂度O(log2n),并且树有多高就需要检索多少次，磁盘读取数据的时间就会增多
- B树，改进的二叉树降低了树的高度，数据根据没有磁盘存储，每个节点都存储着多个元素，所有叶子节点处于同一层，但是没有指针相连接，虽然B数让磁盘io的次数减少了，但是不支持范围查询的快速查找，查找到范围查询的第一个值之后需要重新返回根节点进行多次查询，并且数据存储的是行记录，随着列数增多而空间增大。
- B+树，非叶子节点不存储数据，并且叶子节点之间通过指针相连接，改进了B数的缺点，降低了树的高度，减少磁盘IO，并且叶子节点双向指针，并且有序，提高了查找的效率
什么是 MVCC？
要点：
1.Undo 日志
- Redo记录了事务的行为，通过Redo可以对数据进行重做。而Undo日志记录数据，回滚使用的还是Undo日志。
- 未提交读跟串行化加锁不存在Undo日志，可重复读，跟提交读需要用到版本链跟undo日志
- 对于更新和修改操作，InnoDB并不是删除Undo里边的记录而是将数据删除标志修改为1.并且需要回收机制进行回收。Undo日志有两种，一种插入日志，一种更新日志，插入数据本身只能在本事务中能看到，所以插入日志在事务提交的时候就会被删除。更新日志事务提交不删除，存入指定位置，需要线程进行删除。
- Undo存放在段中也就是存放在系统表空间的段中
- 在对数据新增和修改的时候存在，会产生Redo日志，也会存在Undo日志。也就是事务或者语句执行失败了，可以使用Undo日志恢复数据到修改之前，MVCC中的Undo日志使得事务可以做到读不加锁，读写不冲突。
2.ReadView
- 多并发控制版本链。ReadView可以判断那个版本的Undo日志是否在本事务中可读
- 版本链中存在4个列
- 版本链在第一次查询的时候会生成
- ReadView是一种存储事务id的表，主要包含当前系统中活跃的读写事务的版本id
- m_ids：活跃列表事务id集合
- m_low_limit_id：版本链事务id下限，当前活跃事务id的最小值，m_ids中的最小事务id
- m_up_limit_id：版本链事务id上限，系统中应该分配给下一个事务的id的值
- m_creator_trx_id:生产当前版本链的事务id
3.如何判断可见性
- 每个事务都具有版本链，通过版本链ReadView和Undo日志
- 提交读每次查询都会生成一个事务id,可重复读一次事务中的查询都是一个事务di
- 事务开启第一次查询的时候会生成版本链，根据Undo日志跟ReadView
- 如果被访问的版本trx_id事务id小于ReadView版本链id最小值，表明改事务已经提交，可以被看见
- 事务id等于事务链上的编号，可以被看见
- 事务id大于版本链id,不能被看见
- 事务id在版本链最大值与最小值之间，事务id与版本链这部分的列表内id相对应则不能看见,不与之对应能看见