1. ReadView 案例，解释为什么 RR 和 RC 隔离级别下看到查询结果不一致

案例 01- 读已提交 RC 隔离级别下的可见性分析

开启两个回话，会话事务级别都是READ-COMMITED;

 

操作步骤

1. 开启两个数据库会话，设置事务为提交读
2. 事务2查询id=1数据，查询到的是linda
3. 事务1提交事务
4. 事务2查询id=1的数据，任然为Recentlyzhuzhu2
5. 事务1对id=1的数据进行修改，修改为linda
6. 两边开启事务，两边对查询id=1的数据，为Recentlyzhuzhu2

案例过程

 

结论与分析

• 提交读，解决了幻读跟不可重复读
• 但是存在幻读的问题，在事务2中同一条查询查到不同的数据

案例 02- 可重复读 RR 隔离级别下的可见性分析

开启两个回话，会话事务级别都是REPEATABLE-READ

 

操作步骤

1. 开启两个数据库会话，设置事务为可重复读
2. 事务1查询id=1数据，查询到的是zhuting2
3. 事务2提交事务
4. 事务1查询id=1数据，查询到的是Recentlyzhuzhu
5. 事务2对id=1数据进行更新为zhuting2
6. 事务2查询id=1的数据，任然为linda
7. 事务1对id=1的数据进行修改，修改为zhuting,事务1再次修改Recentlyzhuzhu
8. 两边开启事务

案例过程

 

结论与分析

1. 可重复读，在本会话中查询到的数据都是一致的，解决了幻读，不可重复读，脏读，即使事务1提交了事务，在事务2的会话中还是读取到最原始的数据。
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.索引创建的原则是什么？

1. 表记录很少不需要创建索引
2. 频繁出现where条件，排序，分组字段的需要创建索引提高性能
3. 频繁查询的列，可以创建索引
4. 多表关联，两边都有的字段可以创建索引
5. 一个表不能有过多的索引
6. 无序的列最好别做索引
7. 最好使用组合索引，多个单索引浪费空间，组合索引可以把频繁的列放在最前面
8. 避免使用很长的字段做索引

5.有哪些使用索引的注意事项？

1. like,or,is not null,is null ，!=,<>,字段的使用会使得索引失效
2. select * 全查索引也会失效
3. 使用函数，计算，类型转换索引会失效
4. 字符串不加单引号索引会失效

6.如何知道 SQL 是否用到了索引？

1. 通过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相对应则不能看见,不与之对应能看见