MySql 中的 B+树索引和哈希索引

目录

一. 前言

二. B-Tree 索引

三. 哈希索引

3.1. 哈希索引的实现原理

3.2. 哈希索引的使用场景

四. 索引的缺点


一. 前言

    索引是存储引擎用于快速找到记录的一种数据结构。索引对于数据库良好的性能十分关键,尤其是表中的数据量越来越大时,索引对性能的影响十分明显。

    《高性能MySQL》中对索引的评价是:索引优化应该是对查询性能优化最有效的手段了,索引能够轻而易举将查询性能提高几个数量级。

    以 innodb 为例,innodb 中存储数据的基本元素是,页里面保存了许多数据记录,各个记录通过链表串联起来。一个 innodb 页的结构为:

MySql 中的 B+树索引和哈希索引_第1张图片

innodb 给每个页分配了 16KB 的大小,除了存储用户记录以外还有一些额外的字段没有展示出来。用户记录并不是一定装满了整个页,因此除了用户记录以外还有一部分未使用的空间,后续的新纪录可以继续插入到未使用空间中。

注:在 MySql 中,单条记录的大小不能超过 16K(text、blob 等类型除外)。

除了页内的记录用链表串起来了之外,每个页面也是通过链表连接起来的:

MySql 中的 B+树索引和哈希索引_第2张图片

试想正常情况下,如果想要找到一条记录应该怎么找呢?首先要遍历所有的页面,然后遍历页面里面的记录,一条条记录对比,找到需要查询的记录。这样的话时间复杂度是 O(N),N 代表总的记录条数。

如果数据库中只有几条或者几十条记录,查起来或许还行。但是如果数据库有几千万甚至上亿条记录,这么查起来是什么样子?MySql 数据是写在磁盘上的,一次磁盘寻址所需要的时间是10ms,如果有1亿条记录,那么执行一次查询需要10亿毫秒,也就是1百万秒,算下来需要11.5天。这种级别的耗时是任何一个业务系统都无法忍受的。

而索引存在的意义就在于此,通过特定的结构来排布整个数据库,使得系统能在较快的时间内查询到记录。索引就像是一本书的目录,告诉你哪一章在哪一页,想看对应的章节直接放到对应页数就可以了。

一个最简单的索引思路是:把所有的记录排序,通过二分查找的方式来查找元素,查询的时间复杂度是 O(logN)。这样的话1亿条记录,只需要20多次查询就可以了,算下来时间不到1秒,相比之前的11天已经不是一个数量级了。当然,实际的索引实现也不仅仅是二分查找这么简单。

最常用的索引有两种:

  1. B-Tree 索引,基于 B+树结构的索引。
  2. 哈希索引,基于哈希表实现的索引。

大部分时候,使用的都是 B-Tree 索引。关于 B+树结构可以参见《详解B-Tree和B+Tree》。

二. B-Tree 索引

B-Tree 索引是一种基于 B+树结构的索引,B+树因为其独特的结构优势所以被广泛应用于索引中:

  1. 一个节点包含了多个数据域,适应于操作系统成块访问磁盘的特性,可以一次读取多个节点的数据。
  2. 相对于 B树来说,B+树非叶子节点不包含任何数据,只包含子节点指针 ,因此一个节点所能指向的子节点个数更多,这样的话 B+树会更矮,查询起来更高效。

一个 B-Tree 索引的结构为(橙色是数据域,绿色是子节点指针):

MySql 中的 B+树索引和哈希索引_第3张图片

如果想要找到 id 等于32的记录,首先通过页1定位到子页10,然后继续查找页10,定位到页31,最终找到32。

可以看出,查找的效率是与 B+树的层数相关的,树越高,查找效率越慢,树越低,查找效率越快。实际的应用中,一个页远远不止上面展示的3个记录项,按照一行记录100字节来算,一页数据(16K)至少可容纳1500个记录,那么1亿条记录只需要三层树(10^{9} < 1500*1500*1500)。也就是说,1亿条数据最多执行三次 IO 就能定位到,可见其效率之高。

索引除了可以按值查找以外,还支持对 ORDER BY 子句的排序,只要排序字段也正确匹配上了索引就可以。

B-Tree 支持的索引匹配条件:

  1. 全部匹配:支持同时匹配多个索引。
  2. 部分匹配:支持同时匹配多个索引中的部分索引。
  3. 匹配列前缀:对添加了索引的列,可以匹配其左前缀。例如匹配 maqian 中的前缀 ma。
  4. 匹配范围:支持对索引列去范围值。

三. 哈希索引

哈希索引是一种基于哈希表的索引结构,它是一种需要精确匹配才生效的索引结构。

3.1. 哈希索引的实现原理

实现原理:对索引列计算哈希值把记录映射到哈希槽中,然后指向对应记录行的地址。因此,在查询的时候只要正确匹配到索引列,就能在 O(1) 的时间复杂度内查到记录。

以下是一个哈希索引的示例,左边是哈希槽,右边是对应的数据列:

MySql 中的 B+树索引和哈希索引_第4张图片

相比于 B-Tree 索引而言,哈希索引有不少的局限性:

  1. 哈希索引不支持排序;
  2. 哈希索引不支持部分列索引查找;
  3. 哈希索引只支持等值查询,无法提供范围查询功能。

哈希索引的查找效率是非常高的,大多数时候都能在 O(1) 的时间内找到记录,除非哈希冲突很高。

innodb 中有一个内建功能叫自适应哈希,当存储引擎注意到有列频繁访问的时候,就会建立对应的哈希索引。这样,引擎就同时拥有了 B-Tree 索引和哈希索引,就能使用更加快速的查找。这是一个无需人工干预的自动行为。

3.2. 哈希索引的使用场景

    哈希索引常见的一种场景是针对长字符串查询的优化,例如数据库中保存了大量的 URL 信息,查询 URL 中不可能一个字符一个字符去搜索,这样效率太低。

    这种情况就可以使用哈希索引:给所有的 URL 计算一个 crc 保存起来,然后对 crc 做哈希索引。查询的时候指定 crc 和 url 就能快速定位到记录了。如:

SELECT * FROM url_info WHERE crc = xxxx AND url = 'http://www.baidu.com'

执行这条语句的时候,会先针对 crc 查找哈希索引,找出所有 crc 值等于xxxx的记录,过滤掉大多数不符合条件的记录。然后再根据后面的 url 信息详细匹配,这样查询效率就很高了。

四. 索引的缺点

所有的优点是查询速率很快,但同时也有缺点。

索引的主要缺点是会导致插入和更新语句变慢,因为每次更新数据都要重新维护索引,索引越多,耗时越长。

同时,如果建立了不恰当的索引可能还会导致数据库性能更低,这个就依赖人工的操作了。

你可能感兴趣的:(MySql,b树,b-tree索引,哈希索引,mysql索引)