21、【对线面试官】Mysql索引
我看你简历上写了MySQL，对MySQL InnoDB引擎的索引了解吗？
- 嗯啊，使用索引可以加快查询速度，其实上就是将无序的数据变成有序（有序就能加快检索速度）
- 在InnoDB引擎中，索引的底层数据结构是**
B+树**
那为什么不使用红黑树或者B树呢？
MySQL的数据是存储在硬盘的，在查询时一般是不能「一次性」把全部数据加载到内存中
红黑树是「二叉查找树」的变种，一个Node节点只能存储一个Key和一个Value
B和B+树跟红黑树不一样，它们算是「多路搜索树」，相较于「二叉搜索树」而言，一个Node节点可以存储的信息会更多，「多路搜索树」的高度会比「二叉搜索树」更低。
了解了区别之后，其实就很容易发现，在数据不能一次加载至内存的场景下，数据需要被检索出来
选择B或B+树的理由就很充分了（一个Node节点存储信息更多（相较于二叉搜索树），树的高度更低，树的高度影响检索的速度）
B+树相对于B树而言，它又有两种特性。
1）B+树非叶子节点不存储数据，在相同的数据量下，B+树更加矮壮。（这个应该不用多解释了，数据都存储在叶子节点上，非叶子节点的存储能存储更多的索引，所以整棵树就更加矮壮）
2）B+树叶子节点之间组成一个链表，方便于遍历查询（遍历操作在MySQL中比较常见）
我稍微解释一下吧，你可以脑补下画面
我们在MySQL InnoDB引擎下，每创建一个索引，相当于生成了一颗B+树。
如果该索引是「聚集（聚簇）索引」，那当前B+树的叶子节点存储着「主键和当前行的数据」
如果该索引是「非聚簇索引小」，那当前B+树的叶子节点存储着「主键和当前索引列值」
比如写了一句sql：select*from user where id>=10，那只要定位到id为10的记录，然后在叶子节点之间通过遍历链表（叶子节点组成的链表），即可找到往后的记录了。
由于B树是会在非叶子节点也存储数据，要遍历的时候可能就得跨层检索，相对麻烦些。
基于树的层级以及业务使用场景的特性，所以MySQL选择了B+树作为索引的底层数据结构。
对于哈希结构，其实InnoDB引擎是「自适应」哈希索引的（hash索引的创建由lnnoDB存储引擎自动优化创建，我们是干预不了）
你知道什么是回表吗？
- 所谓的回表其实就是，当我们使用非聚簇索引查询数据时，检索出来的数据可能包含其他列
- 但走的索引树叶子节点只能查到当前列值以及主键ID，所以需要根据主键ID再去查一遍数据，得到SQL所需的列
- 举个例子，我这边建了给订单号ID建了个索引，但我的SQL是：select orderld，orderName from orderdetail where orderld = 123
- SQL走订单ID索引，但在订单ID的索引树的叶子节点只有orderld和ld，而我们还想检索出orderName，所以MySQL会拿到ID再去查出orderName给我们返回，这种操作就叫回表
如何避免回表
- 想要避免回表，可以使用覆盖索引
- 所谓的覆盖索引，实际上就是你想要查出的列刚好在叶子节点上都存在，比如我建了orderld和orderName.联合索引l，刚好我需要查询也是orderld和orderName，这些数据都存在索引树的叶子节点上，就不需要回表操作了。
既然你也提到了联合索引，我想问下你了解最左匹配原则吗
- 嗯，要说明这个概念，还是举例子比较容易
- 如有索引（a，b，c，d），查询条件a=1and b=2 and c>3 and d=4，则会在每个节点依次命中a、b、c，无法命中d
- 先匹配最左边的，索引只能用于查找key是否存在（相等），遇到范围查询（>、<、between、like左匹配）等就不能进一步匹配了，后续退化为线性查找
- 这就是最左匹配原则
嗯嗯，我还想问下你们主键是怎么生成的？
主键就自增的
那假设我不用MySQL自增的主键，你觉得会有什么问题呢？
- 首先主键得保证它的唯一性和空间尽可能短吧，这两块是需要考虑的。
- 另外，由于索引的特性（有序），如果生成像uuid类似的主键，那插入的的性能是比自增的要差的
- 因为生成的uuid，在插入时有可能需要移动磁盘块（比如，块内的空间在当前时刻已经存储满了，但新生成的uuid需要插入已满的块内，就需要移动块的数据）