6、索引的数据结构

3.3 常见的索引概念

索引按照物理实现方式,索引可以分为 2 种:聚簇非聚簇索引

1、聚簇索引

5、索引的代价

  • 空间上的代价
    每建立一个索引都要为它建立一棵B+树,每一棵B+树的每一个节点都是一个数据页,一个页默认会占用 16KB 的存储空间,一棵很大的B+树由许多数据页组成,那就是很大的一片存储空间。

  • 时间上的代价
    每次对表中的数据进行 增、删、改 操作时,都需要去修改各个B+树索引

6、MySQL数据结构选择的合理性

从MySQL的角度讲,不得不考虑的一个现实问题就是磁盘IO,如果我们能让索引的数据结构尽量减少硬盘的I/O操作,所消耗的时间也就越小。可以说:磁盘的I/O次数对索引的使用效率至关重要

查找都是索引操作,一般来说索引非常大,尤其是关系型数据库,当数据量比较大的时候,索引的大小有可能几个G甚至更多,为了减少索引在内存中的占用,索引都是存储在外部磁盘上的。当我们利用索引查询的时候,不可能将整个索引全部加载到内存,只能逐一加载,那么MySQL衡量查询效率的标准就是磁盘的IO次数

6.1 全表遍历

6.2 Hash结构

6、索引的数据结构_第1张图片
上图中哈希函数h有可能将两个不同的关键字映射到相同的位置,这叫做 碰撞 ,在数据库中一般采用 链接法来解决。在链接法中,将散列到同一槽位的元素放在一个链表中,如下图所示:
6、索引的数据结构_第2张图片

Hash结构效率高,那为什么索引结构要设计成树型呢?
6、索引的数据结构_第3张图片
Hash索引的适用性:
InnoDB本身你不支持Hash索引,但是提供自适应的Hash索引。采用自适应 Hash 索引目的是方便根据 SQL 的查询条件加速定位到叶子节点,特别是当 B+ 树比较深的时候,通过自适应 Hash 索引可以明显提高数据的检索效率。

6.3 二叉搜索树

如果我们利用二叉树作为索引结构,那么磁盘的IO次数和索引树的高度是相关的。
6、索引的数据结构_第4张图片

为了提高查询效率,就需要 减少磁盘IO数 。为了减少磁盘IO的次数,就需要尽量 降低树的高度 ,需要把原来“瘦高”的树结构变的“矮胖”,树的每层的分叉越多越好。

6.4 AVL树 (平衡二叉树)

左右子树的高度差不能超过 1
6、索引的数据结构_第5张图片

6.5 B-Tree

B树的英文是Balance Tree,也就是多路平衡查找树,它的高度远小于平衡二叉树的高度

B 树的结构如下图所示:
6、索引的数据结构_第6张图片
一个 M 阶的 B 树(M>2)有以下的特性:

  • 根节点的儿子数的范围是 [2,M]。
  • 每个中间节点包含 k-1 个关键字和 k 个孩子,孩子的数量 = 关键字的数量 +1,k 的取值范围为[ceil(M/2), M]。
  • 叶子节点包括 k-1 个关键字(叶子节点没有孩子),k 的取值范围为 [ceil(M/2), M]。
  • 假设中间节点节点的关键字为:Key[1], Key[2], …, Key[k-1],且关键字按照升序排序,即 Key[i]
  • 所有叶子节点位于同一层。

6.6 B+Tree

B+ 树和 B 树的差异:

你可能感兴趣的:(MySql,mysql)