摘要
索引 是数据库里重要的组成部分，也是进步查问效率必备的知识点。本文将会介绍 索引作用 、 索引类型 、 索引优化 以及 索引底层构造 ，也算是对索引常识的一次 演绎。
一、索引介绍
什么是索引？
数据库 是用来存储与读取数据的，如何在这宏大的数据中查问咱们想要的那一行呢？最简略的方法便是 扫描 整个数据表，一一比照。然而这样效率太低了。
如果咱们有相似 字典 的性能，在查问某行数据前，先到字典里定位到行地位，再依据行地位找到具体数据，是否能更快呢？是的，索引就是这么设计的。
个别的，咱们往表里插入某一行数据时，总会有额定的信息来定位到这一行。这个信息可能是一个 指针地址 ，也可能是一个 主键标识。
在拿到这一行的 定位信息 后，就能够将 列数据和定位信息 做关联了。下次想查找这个字段列所对应的行数据时，就能够先到关联信息里搜寻，拿到定位信息后间接查找即可。这就是索引，存储了列和定位信息，这定位信息也能够了解指向数据记录的 援用指针。
须要留神的是，索引是由存储引擎这个模块来实现的，不同的存储引擎有不同的实现形式。像 innodb 的主键就蕴含了行数据，找到了主键，也就找到了数据。
索引的分类
在数据库里，索引有好多种。咱们能够从上面几方面来分类演绎。
从数据结构划分 ：B+ 树、hash 索引、全文索引 从物理构造划分 ：汇集索引、非汇集索引 从逻辑用户划分：主键、惟一索引、复合索引、一般单列索引
其中，B+ 树、hash 索引、全文索引将会在前面具体介绍其底层构造，咱们来看看其余的索引：
汇集索引：该索引除了存储索引信息还存储了行数据，像刚刚提到的主键就是。找到它也就象征找到数据了。并且它的排序间接对应了物理存储程序。
非汇集索引：该索引除了存储索引信息还存储了定位到数据记录的信息，须要依据这个信息再做一次查问，能力获取到数据，并且它的排序是逻辑上，不是物理存储程序。
主键：惟一地标识表中一条记录的索引，不能有 NULL 值。在 InnoDB 里，主键就是汇集索引。
惟一索引：索引所对应的列值里是不能有反复值的，容许有 NULL 值。像刚刚提到的主键是不容许有 NULL 值的。
复合索引：有多列组合在一起的索引，但只能按最左准则查找，即第一列字段能力被索引查找，前面只是作为附带信息寄存着。次要是为了找到索引后，不须要再去行数据里捞数据，间接从索引里提取字段信息即可。
一般单列索引：没有什么限度条件的索引列。
索引的毛病
引入索引，并不总意味着高效，它是须要付出代价保护的。每当有数据须要增加更新时，都得更新对应的索引，这是额定的性能开销，甚至有可能有呈现死锁。
另外，索引是须要占用磁盘空间的，不能无限度的增加索引，要有针对性的建索引。
二、索引的应用
应用准则
索引之所以那么快，是因为咱们将平时查问频率较高的字段独自保护了起来。当咱们有多个查问选项，多个查问条件就不肯定能发挥作用了，所以索引的应用是有注意事项的，上面总结了一些：
- where 里最常常用到的查问字段才建索引，能利用主键 id，就用主键 id 来增删改查
- 按最左匹配准则，将多个单列索引改为复合索引，缩小保护量
- 尽量挑抉择度高，也就是反复率低的列作为索引，像性别这种列就不适宜了，会在 B+ 树里做多层次多范畴的搜寻，还不如全表扫描呢
- 查找时，不对索引列做函数计算，否则不能应用到索引
- 查问条件尽量用 union 来取代 or
- like 用法：‘列 %’这样还是能够用到索引的，’% 列 %’ 就不行了
- IS NULL，IS NOT NULL 是用不到索引的
- 在 order by，group by 里尽量应用索引字段
- join 的 on 条件里尽量应用索引字段
性能剖析
当咱们应用了索引后，又如何晓得它有没有应用到索引呢？咱们能够借 助执行打算 来剖析，执行打算是 mysql 依据咱们的查问语句进行一系列的剖析后失去的优化计划。咱们能够通过执行打算来获取执行过程。
执行打算的获取：
explain select 语句
波及的字段含意如下：
- id：该 SELECT 标识符
- select_type：该 SELECT 类型
- table：输入行的表
- partitions：匹配的分区
- type：联接类型
- possible_keys：可供选择的可能索引
- key：理论抉择的索引
- key_len：所选密钥的长度
- ref：与索引比拟的列
- rows：预计要查看的行数
- filtered：按表条件过滤的行百分比
- Extra：附加信息
其中，有个 type 字段，它的含意大略如下：
- eq_ref：应用到了 UNIQUE 或 PRIMARY KEY 索引
- ref：显示索引的哪一列被应用了
- ref_or_null：对 Null 进行了索引优化
- range：索引范畴检索
- index：索引扫描
- unique_subquery：应用了 in 子查问，外面波及了主键字段
- index_subquery：应用了 in 子查问，外面波及了非惟一索引
- fulltext：全文索引
- all：全表扫描数据
从下面大略就能剖析出索引的应用状况了，如果是 all，那就是没有用到索引了。
索引的的底层
后面提到过索引的品种时，细分了 B+ 树、hash 索引、全文索引这三类。当初咱们来具体看下对应的底层构造吧。
B+ 树
在 B+ 树之前还有 二叉搜寻树 和 B 树 ，咱们来一步一步演变，看看有什么不同，先来看 二叉搜寻树：
当要进行查找时，会按小于往左搜寻，大于往右搜寻的规定去寻找。二叉搜寻树只存了单个节点值，树的高度有可能会很高，如果用来存储索引数据，效率将会升高，不适用于 mysql 的索引，咱们来看看 B 树吧：
一个节点能够存储多个数据值。当然，在插入删除时须要做对应的拆分或合并动作。
而且 B 树容许在非叶子节点也存储具体数据，这意味着在扫描搜寻时也会将数据加载进来，这无疑减少了磁盘 IO。
对于磁盘 IO 要求高的 mysql 而言，B 树也很不划算，所以 B+ 树成了最好的抉择，它长这样的：
B+ 树只在 叶子节点 存储具体的数据(注：数据能够是真正的行数据也能够是定位到行数据的指针地址)，而非叶子节点值只寄存索引数据，这样能够升高磁盘 IO，还能充分利用磁盘的预读性能，批量的加载索引数据。
hash 索引
hash 索引将列通过 hash 运算失去 hash code，而后将 hash code 跟数据行的指针地址关联在一起，下次查找时只需查找对应 hash code 的数据行地址即可。
hash 索引十分的紧凑，查找速度很快，实用于内存存储引擎的利用。不过它只能准确查问，不反对范畴查找，也不能间接进行排序。限度还是挺多的。
全文索引
全文索引次要是用于文档查找，像咱们可能会从多篇文章中查找蕴含某些词语的文章，这时就能够应用全文索引了。尽管 like 也能够应用，然而效率太低了。
全文索引在接管到文档时，会对它进行分词解决，以获取到关键词。而后会将关键词和属于这个文档的 id 关联起来。
下次查找，就会先到关键词列表里找到关联的文档 id，最初利用文档 id 去查找到文档数据。
总结
索引所波及的知识点还是挺多的，从 理解索引 到用好索引 再到 优化索引，我想这应该是咱们进行查问优化的必经之路吧。心愿本文能为大家带来不一样的意识，也欢送一起探讨！
感兴趣的敌人能够搜一搜公众号「阅新技术」，关注更多的推送文章。
能够的话，就顺便点个赞、留个言、分享下，感激各位反对！
阅新技术，浏览更多的新常识。