《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法

5.1 InnoDB存储引擎索引概述

InnoDB支持两种常见的索引

  • B+树索引
  • 哈希索引(自适应的,会根据表的使用情况自动生成,不能人为干预)
    一个常被忽略的问题:
    B+树索引并不能找到一个给定键值的具体行,只能找到被查数据所在的页,然后数据库将此页读入内存,再在页中查找最后得到数据。

5.2 二分查找法

每页Page Directory中的槽是按照主键的顺序存放的,对于某一条具体记录的查询是通过对Page Directory进行二分查找得到的。

5.3 平衡二叉树

《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第1张图片
二叉查找树
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第2张图片
制杖二叉查找树

若想最大性能的构造一个二叉查找树,需要这棵树是平衡的 -- 平衡二叉树,或称AVL树,平衡二叉树并不一定是最优二叉树。
维护平衡二叉树必然有一定的开销, 不过多用于内存结构对象中,所以开销相对较小

5.4 B+树

《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第3张图片
B+树

5.4.1 B+树的插入操作

《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第4张图片
B+树插入情况

《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第5张图片
插入28
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第6张图片
插入70
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第7张图片
插入95

5.4.2 B+树的删除操作

B+树用填充因子(fill factor)来控制树的删除变化,50%是填充因子可设的最小值。


《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第8张图片
B+树删除
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第9张图片
删除70
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第10张图片
删除60

5.5 B+树索引

B+索引在数据库中一个特点就是其高扇出性,在数据库中,高度一般都是在2-3层,也就是查询一个数据,最多只需要2-3次IO。
B+树索引可以分为聚集索引(clustered index)和辅助聚集索引(secondary index)。其不同点是,叶节点存放的是否是一整行的信息。

5.5.1 聚集索引

InnoDB存储引擎表是索引组织表,即表中数据按照主键顺序存放。而聚集索引就是按照每张表的主键构造一棵B+树,叶节点中存放的整张表的行记录数据,因此也让聚集索引的叶节点成为数据页。聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。同B+树一样,每个数据页都通过一个双向链表来进行链接。

  • 聚集索引可以让我们在索引的叶节点上直接找到数据;
  • 此外由于定义了数据的逻辑顺序,聚集索引能够特别快的访问针对范围值的查询,查询优化器能够快速发现某一段范围的数据页需要扫描。
  • 聚集索引对于主键的排序查找和范围查找速度非常快

5.5.2 辅助索引(非聚集索引)

页级别不包含行的全部数据。叶节点除了包含键值以外,每个叶级别的索引行中还包含了一个书签,该书签用来告诉InnoDB哪里可以找到与索引相对应的行数据,实际上,辅助索引的书签就是聚集索引键。


《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第11张图片
聚集索引与辅助索引关系

5.5.3 B+树索引的管理

索引创建和删除方式


《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第12张图片
ALTER TABLE 1

ALTER TABLE 2
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第13张图片
CREATE/DROP

目前对于索引的添加或者删除,均为创建一个临时表,把数据导入临时表,删除原表,重命名临时表,所以大表操作索引也会很费时间。
但是InnoDB Plugin开始,支持一种称为快速索引创建方法,当时只限于辅助索引,对于索引的创建,不用重新建表,而是加上一个S锁。删除时,在内部视图更新下,将辅助索引的空间标记为空,并删除MySQL内部视图上对于该表的索引定义即可。

5.6 B+树索引的使用

5.6.1 什么时候使用B+树索引

访问表中很少一部分行时,才有建表必要(高选择性)。而对于取出很多行时,没有必要建立索引。
及时高选择性的字段,但是取出大部分数据,此时不会使用索引(日期范围等情况)

5.6.2 顺序读、随机读与预读取

预读取,通过一次IO将预测会访问的多个页缓存下来

  • 随机预读取。一个区中有一部分页被频繁访问,则预读本区整个区。
  • 线性预读取。一个区多少页被顺序访问,则预读下个区的所有页。

很尴尬的是,预读取关闭时比开启性能还要好,InnoDB Plugin1.0.4后随机访问的预读取关了,但是线性预读取还是保留了。

当前数据库策略并不适合固态硬盘

5.6.3 辅助索引的优化使用

当辅助索引叶节点有足够数据时(比如只查询主键),数据库会使用辅助索引,但是当对主键order by 或者强制使用聚集索引,就会用回聚集索引

5.6.4 联合索引

对表上多个列做索引,按顺序使用索引列才会命中,因为单独看后面的列,并没有按顺序摆放。

5.7 哈希算法

5.7.1 哈希表

《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第14张图片
直接寻址表
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第15张图片
哈希表
《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法_第16张图片
链表法解决碰撞

5.7.2 InnoDB中的哈希算法

5.7.3 自适应哈希索引


欢迎大家关注我的公众号


半亩房顶

你可能感兴趣的:(《MySQL技术内幕:InnoDB存储引擎》第五章 索引与算法)