MySQL八股文高频（事务、索引、MVCC、锁）

事务

1.事务的四大特性

原子性

要么同时成功，要么同时失败

是用undolog来保证事务的原子性

undolog是MySQL的回滚日志，undolog有三个隐藏字段：transaction ID, roll ptr, (row_id)

undolog版本链会记录每一次变更前的数据，链表的表头是最新修改的数据，尾部是最早修改的数据

一致性

由undolog和redolog来保证事务的一致性

redolog是缓存刷新脏页到磁盘失败的时候，用redolog来恢复数据，保证了数据的持久性和一致性

隔离性

MySQL四大隔离机制：read uncommited, read committted, repeatable read(InnoDB默认), serializable

read committed 解决了脏读的问题

repeatable read解决了脏读、不可重复读的问题

serializable解决的脏读、不可重复读、幻读的问题

什么是脏读？

事务A可以读到事务B还没commit的数据

什么是不可重复读？

事务A两次读取同一条数据的时候，数据不一样（中间事务B对这条数据进行了update操作）

什么是幻读？

事务A select一条数据的时候显示不存在，尝试insert的时候却显示存在了。再select还是显示不存在好像出现了幻象

read commited是怎么解决脏读的？

在RC中，会在每一次快照读的时候生成readview，根据readview的四个字段（正在活跃的事务合集、最小活跃事务ID、预分配事务ID、创建这个readview的事务ID），在undolog版本链中找到这一次快照读该返回的数据

repeatable read是怎么解决不可重复读的？

在RR中，只会在第一次快照读的时候生成readview, 之后快照读都会沿用这个readview，因为readview一样在undolog版本链中找到的这次快照读返回的数据也都一样。保证了可重复读。

serializable是怎么解决幻读的？

通过加间隙锁或者临键锁

持久性

redolog是缓存刷新脏页到磁盘失败的时候，用redolog来恢复数据，保证了数据的持久性和一致性

redolog有两部分：redolog buffer和redolog file，redolog buffer在缓存中, redolog file在磁盘中。每一次数据页变化缓存在redolog buffer中，通过后台线程异步刷新到redolog file中。当脏页刷新到磁盘发生错误的时候，就可以通过redolog file恢复。顺序磁盘IO > 随机磁盘IO

索引

索引的分类

主键索引、唯一索引、常规索引、全文索引

聚集索引和非聚集索引（二级索引）

聚集索引和非聚集索引的区别？

聚集索引：叶子结点下面存的是行数据；非聚集索引叶子结点下面存的是主键

索引底层是怎么实现的？

InnoDB存储引擎下，索引底层是用B+Tree实现的

为什么使用B+Tree这种数据结构？为什么不使用BST、红黑树、或者BTree？

BST在顺序插入时形成一个单向链表，搜索效率极低

红黑树解决的BST在顺序插入时形成一个单向链表的问题，但是红黑树毕竟也是二叉树，一个Node只能最多有两个孩子，树的层高也会很高，搜索效率一般

BTree解决了红黑树一个Node只能最多有两个孩子的问题。BTree和B+Tree的区别是：B+Tree只在叶子结点上存数据，其他结点只做索引的作用，但BTree在每个Node都存了数据。因为每个Node的数据和指针都存在页中，每个页的大小是固定的：16KB，BTree的Node既存了数据也存了指针，那么可以存放的指针个数就比B+Tree少。所以B+Tree更扁平一些，B+Tree相比BTree磁盘IO少。

B+Tree还有一个特点：叶子结点形成双向链表，这个可以大大增加区间访问性。B+Tree可以很好的利用空间局部性原理，减少磁盘IO

索引失效的情况