mysql 系列(搞定索引)

摘要 索引是数据库里重要的组成部分,也是提高查询效率必备的知识点。本文将会介绍索引作用、索引类型、索引优化以及索引底层结构,也算是对索引知识的一次归纳。
一、索引介绍 什么是索引? 数据库是用来存储与读取数据的,如何在这庞大的数据中查询我们想要的那一行呢?最简单的办法便是扫描整个数据表,一一对比。然而这样效率太低了。
如果我们有类似字典的功能,在查询某行数据前,先到字典里定位到行位置,再根据行位置找到具体数据,是否能更快呢?是的,索引就是这么设计的。
一般的,我们往表里插入某一行数据时,总会有额外的信息来定位到这一行。这个信息可能是一个指针地址,也可能是一个主键标识。
在拿到这一行的定位信息后,就可以将列数据和定位信息做关联了。下次想查找这个字段列所对应的行数据时,就可以先到关联信息里搜索,拿到定位信息后直接查找即可。这就是索引,存储了列和定位信息,这定位信息也可以理解指向数据记录的引用指针。
需要注意的是,索引是由存储引擎这个模块来实现的,不同的存储引擎有不同的实现方式。像 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 语句
mysql 系列(搞定索引)
文章图片

涉及的字段含义如下:
  • 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 系列(搞定索引)
文章图片

当要进行查找时,会按小于往左搜索,大于往右搜索的规则去寻找。二叉搜索树只存了单个节点值,树的高度有可能会很高,如果用来存储索引数据,效率将会降低,不适用于 mysql 的索引,我们来看看 B 树吧:
mysql 系列(搞定索引)
文章图片

一个节点可以存储多个数据值。当然,在插入删除时需要做对应的拆分或合并动作。
而且 B 树允许在非叶子节点也存储具体数据,这意味着在扫描搜索时也会将数据加载进来,这无疑增加了磁盘 IO。
对于磁盘 IO 要求高的 mysql 而言,B 树也很不划算,所以 B+ 树成了最好的选择,它长这样的:
mysql 系列(搞定索引)
文章图片

B+ 树只在叶子节点存储具体的数据(注:数据可以是真正的行数据也可以是定位到行数据的指针地址),而非叶子节点值只存放索引数据,这样可以降低磁盘 IO,还能充分利用磁盘的预读功能,批量的加载索引数据。
hash 索引 mysql 系列(搞定索引)
文章图片

hash 索引将列通过 hash 运算得到 hash code,然后将 hash code 跟数据行的指针地址关联在一起,下次查找时只需查找对应 hash code 的数据行地址即可。
hash 索引非常的紧凑,查找速度很快,适用于内存存储引擎的应用。不过它只能精确查询,不支持范围查找,也不能直接进行排序。限制还是挺多的。
全文索引 全文索引主要是用于文档查找,像我们可能会从多篇文章中查找包含某些词语的文章,这时就可以使用全文索引了。虽然 like 也可以使用,但是效率太低了。
全文索引在接收到文档时,会对它进行分词处理,以获取到关键词。然后会将关键词和属于这个文档的 id 关联起来。
下次查找,就会先到关键词列表里找到关联的文档 id ,最后利用文档 id 去查找到文档数据。
总结 索引所涉及的知识点还是挺多的,从了解索引到用好索引再到优化索引,我想这应该是我们进行查询优化的必经之路吧。希望本文能为大家带来不一样的认识,也欢迎一起探讨!
【mysql 系列(搞定索引)】感兴趣的朋友可以搜一搜公众号「 阅新技术 」,关注更多的推送文章。
可以的话,就顺便点个赞、留个言、分享下,感谢各位支持!
阅新技术,阅读更多的新知识。
mysql 系列(搞定索引)
文章图片

    推荐阅读