Mysql-(二)-mysql中的索引
1. 索引的一句话解释
数据库索引，是数据库管理系统(DBMS)中一个排序的数据结构，以协助快速查询、 更新数据库表中数据。
「索引就像书的目录， 通过书的目录就准确的定位到了书籍具体的内容」。
数据是以文件的形式存放在磁盘上面的，每一行数据都有它的磁盘地址。
如果没有索引的话，我们要从全量数据里面检索一条数据，只能依次遍历这张表的全部数据 (循环调用存储引擎的读取下一行数据的接口)，直到找到这条数据。
但是我们有了索引之后，只需要在索引里面去检索这条数据就行了，因为它是一种特殊的专门用来快速检索的数据结构，我们找到数据存放的磁盘地址以后，就可以拿到数据了。
2. 索引的数据结构应该是怎么样的
就像字典，提供了以 拼字字母 的查找方式 、偏旁部首的查找方式，呢么数据库索引该提供了怎么样的方式？又是选用什么样的数据结构来存储索引呢？
若数据结构为BST 会是怎么样呢？
二叉查找树既能够实现快速查找，又能够实现快速插入。
但是二叉查找树有一个问题，就是它的查找耗时是和这棵树的深度相关的，在最坏的情况下时间复杂度会退化成O(n)。
若数据结构为AVL 会是怎么样呢？
维护角度：为了保持平衡，AVL 树在插入和更新数据的时候执行了一系列的计算和调整的操作。
存储角度：在平衡二叉树中，一个节点，它的大小是一个固定的单位，作为索引应该存储什么内容?
- 第一个是索引的键值。比如我们在 id 上面创建了一个索引，我在用 where id =1 的 条件查询的时候就会找到索引里面的 id的这个键值。
- 第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。
- 第三个，因为是二叉树，它必须还要有左子节点和右子节点的引用，这样我们才能 找到下一个节点。
查询角度+存储角度 ：当我们用树的结构来存储索引的时候，访问一个节点就要跟磁盘之间发生一 次 IO。
InnoDB操作磁盘的最小的单位是一页(或者叫一个磁盘块)，大小是 16K(16384 字节)。
那么，一个树的节点就是 16K 的大小，节点只存一个键值+数据+引用，例如整形的字段，可能只用了十几个 或者几十个字节，它远远达不到 16K 的容量，访问一个树节点，进行一次 IO 的时候， 浪费了大量的空间。
若数据结构为 多路平衡查找树(B Tree) 会怎么样呢？
跟 AVL 树一样，B 树在枝节点和叶子节点存储键值、数据地址、节点引用。
它有一个特点:分叉数(路数)永远比关键字数多 1。 比如我们画的这棵树，每个节点存储两个关键字，那么就会有三个指针指向三个子节点。
那 B Tree 又是怎么实现一个节点存储多个关键字，还保持平衡的呢?跟 AVL 树有什么区别? 对不起我回答不上来这个问题；
多路平衡查找树(B + Tree) 比 B tree 好在哪里？
二者区别：
- 它的关键字的数量是跟路数相等的;
- B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。 目前的认知:我们这要存放的数据是什么?是不是真实数据的地址? 搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索
id=28，虽然在第一层直接命中了，但是数据地址在叶子节点上面，所以我还要继续往下搜索，一 直到叶子节点。- B+Tree 的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数 据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。
带来的优势：
- 它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。(每个节点存储更多关键字;路数更多)
- 扫库、扫表能力更强(对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵 B+Tree 拿到所有的数据)
- B+Tree 的磁盘读写能力相对于 B Tree 来说更强(根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多)
- 排序能力更强(因为叶子节点上有下一个数据区的指针，数据形成了链表)
5.)效率更加稳定(B+Tree 永远是在叶子节点拿到数据，所以 IO 次数是稳定的)
3. 不同存储引擎上的索引
3.1 MyISAM
在 MyISAM 里面，另外有两个文件:
-
一个是.MYD 文件，D 代表 Data，是 MyISAM 的数据文件，存放数据记录，比如我们的 user_myisam表的所有的表数据。
-
一个是.MYI 文件，I 代表 Index，是 MyISAM 的索引文件，存放索引，比如我们在 id 字段上面创建了一个主键索引，那么主键索引就是在这个索引文件里面。
也就是说，在 MyISAM 里面，索引和数据是两个独立的文件。 那我们怎么根据索引找到数据呢?
MyISAM 的 B+Tree 里面，叶子节点存储的是数据文件对应的磁盘地址。
所以从索引文件.MYI 中找到键值后，会到数据文件.MYD 中获取相应的数据记录。
3.2 InnoDB
在 InnoDB 里面，它是以主键为索引来组织数据的存储的，所以索引文件和数据文 件是同一个文件，都在.ibd 文件里面，在 InnoDB 的主键索引的叶子节点上，它直接存储了我们的数据。
聚集索引(聚簇索引):就是索引键值的逻辑顺序跟表数据行的物理存储顺序是一 致的。(比如字典的目录是按拼音排序的，内容也是按拼音排序的，按拼音排序的这种 目录就叫聚集索引)。
在 InnoDB 里面，它组织数据的方式叫做叫做(聚集)索引组织表(clustered index organize table)，所以主键索引是聚集索引，非主键都是非聚集索引。
InnoDB 中，主键索引和辅助索引是有一个主次之分的，辅助索引存储的是辅助索引和主键值。
如果使用辅助索引查询，会根据主键值在主键索引中查询，最终取得数据，比如我们用 name 索引查询 name= ‘青山’，它会在叶子节点找到主键值，也就是 id=1，然后再到主键索引的叶子节点拿到数据。
回表:
非主键索引，我们先通过索引找到主键索引的键值，再通过主键值查出索引里面没 有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程就叫回表。
在辅助索引里面，不管是单列索引还是联合索引，如果 select 的数据列只用从索引 中就能够取得，不必从数据区中读取，这时候使用的索引就叫做覆盖索引，这样就避免了回表。
4.什么时候用不到索引
函数、隐式转换、打破最左原则、范围都有可能令索引失效。
其实，用不用索引，最终都是优化器说了算。
优化器是基于什么的优化器?
基于 cost 开销(Cost Base Optimizer)，它不是基于规则(Rule-Based Optimizer)，也不是基于语义。怎么样开销小就怎么来。
使用索引有基本原则，但是没有具体细则，没有什么情况一定用索引，什么情况一定不用索引的规则。