索引及其实现结构

索引（Index）是帮助MySQL高效获取数据的数据结构。可以得到索引的本质：索引是数据结构。
可以理解为“排好序的快速查找数据结构”

在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据,

这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

MySQL索引结构

• BTree索引
• Hash索引
• full-text全文索引
• R-Tree索引

红黑树-> B树->B+树
二叉平衡树->多叉平衡树
内在逻辑就是减小树深，从而降低I/O读取次数
从外存储器中读取信息的步骤，简单来分，大致有两步：

1. 找到存储这个数据所对应的磁盘页面，这个过程是机械化的过程，需要依靠磁臂的转动，找到对应磁道，所以耗时长。
2. 读取数据进内存，并实施运算，这是电子化的过程，相当快。

综上，对于外存储器的信息读取最大的时间消耗在于寻找磁盘页面。

红黑树
二叉查找树->自平衡二叉查找树AVL || 红黑树

AVL和红黑树的区别
平衡指的是树的左右子树的高度差距在一个可控的范围内。图中红黑树也是平衡的，不过红黑树的平衡标准比avl树低。avl树要求左右子树高度差不大于1。而红黑树中红节点的父亲和孩子必须是黑节点，且从根到叶子节点经过的黑节点个数相同，因此红黑树最小深度是路径上只有黑节点，最大深度是路径上红黑节点相互间隔，因此最大深度≤最小深度的两倍，最大深度是2*log2（n+1）。因此，红黑树的查询效率比avl树低，但是红黑树的删除效率比avl树高，更适合大量数据增加删除的场景，而且红黑树在增加删除数据的时候只需要常数次旋转操作，更适合数据持久化的场景。来自知乎

为什么linux内核中更多的是使用红黑树

1. 如果插入一个node引起了树的不平衡，AVL和RB-Tree都是最多只需要2次旋转操作，即两者都是O(1)；但是在**删除**node引起树的不平衡时，最坏情况下，AVL需要维护从被删node到root这条路径上所有node的平衡性，因此需要旋转的量级O(logN)，而RB-Tree最多只需3次旋转，只需要O(1)的复杂度。
2. 其次，AVL的结构相较RB-Tree来说更为平衡，在插入和删除node更容易引起Tree的unbalance，因此在大量数据需要插入或者删除时，AVL需要rebalance的频率会更高。因此，RB-Tree在需要大量插入和删除node的场景下，效率更高。自然，由于AVL高度平衡，因此AVL的search效率更高。
3. map的实现只是折衷了两者在search、insert以及delete下的效率。总体来说，RB-tree的统计性能是高于AVL的。
   来自知乎Acjx

B树

• 需要注意的是：指针，关键字，以及关键字所代表的文件地址这三样东西合起来构成了B树的一个节点，这个节点存储在一个磁盘块上

B+树

• 相对于B树，少了文件位置，所以树会胖（单节点容纳分支指针越多），更浅

B+树和B树相比，主要的不同点在以下3项：

• 内部节点中，关键字的个数与其子树的个数相同，不像B树种，子树的个数总比关键字个数多1个
• 所有指向文件的关键字及其指针都在叶子节点中，不像B树，有的指向文件的关键字是在内部节点中。换句话说，B+树中，内部节点仅仅起到索引的作用，
• 在搜索过程中，如果查询和内部节点的关键字一致，那么搜索过程不停止，而是继续向下搜索这个分支。

根据B+树的结构，我们可以发现B+树相比于B树，在文件系统，数据库系统当中，更有优势，原因如下：

1. B+树的磁盘读写代价更低
   B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说I/O读写次数也就降低了。

2. B+树的查询效率更加稳定
   由于内部结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

3. B+树更有利于对数据库的扫描
   B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题，而B+树只需要遍历叶子节点就可以解决对全部关键字信息的扫描，所以对于数据库中频繁使用的range query，B+树有着更高的性能。

2 聚集/非聚集索引

聚集索引
数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。

非聚集索引
该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。

聚集索引：可以帮助把很大的范围，迅速减小范围。但是查找该记录，就要从这个小范围中Scan了。就是找到数据所在数据块的位置，然后遍历数据块
非聚集索引：把一个很大的范围，转换成一个小的地图。你需要在这个小地图中找你要寻找的信息的位置。然后通过这个位置，再去找你所需要的记录。非聚集索引就是虚拟化成映射表，直接去查找

3 索引基本语法

4 索引优缺点 及 索引适用范围

优势

最主要是加快检索速度
在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间
可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性

• 类似大学图书馆建书目索引，提高数据检索效率，降低数据库的IO成本。
• 通过索引对数据进行排序，降低数据排序的成本，降低了CPU的消耗。

劣势

两点：建表需要时间和空间；后期维护表需要时间（比如增删记录）

• 实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占空间的。
• 虽然索引大大提高了查询速度，同时确会降低更新表的速度，如对表进行INSERT、UPDATE、DELETE。
• 因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段。
• 都会调整因为更新所带来的键值变化后的索引信息。

哪些情况需要创建索引

1. 主键自动建立唯一索引
2. 频繁作为查询条件的字段应该创建索引
3. 查询中与其他表关联的字段，外键关系建立索引
4. 频繁更新的字段不适合建立索引，因为每次更新不单单是更新了记录还会更新索引
5. WHERE条件里用不到的字段不创建索引
6. 单键/组合索引的选择问题，who?(在高并发下倾向创建组合索引)
7. 查询中排序的字段，排序的字段若通过索引去访问将大大提高排序速度
8. 查询中统计或者分组字段

哪些情况不要创建索引

1. 表记录太少
2. 经常增删改的表
   
   1. 提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE、和DELETE。
   2. 因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。
   3. 数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据建立索引。
3. 注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。