※ 树的每个结点都会存储数据
※ 单次查询不一定要遍历到树的根部,平均查询时间会比较快
※ 非叶子节点不存储数据,只存储(冗余)索引,索引包含主键和指针
※ 叶子节点才真正存储数据
※ 每个叶子节点互相链表相连,保证了范围查询的时效性(页之间用双向链表连接,数据间用单项链表链接)
InnoDB最小存储单位是页,叶子节点和非叶子节点最小单位都是页,页大小Mysql 默认设定16384字节,约为16KB。
我们假设主键ID为bigint类型,长度为8字节,而指针大小在InnoDB源码中设置为6字节,这样一共14字节
我们一个页中能存放多少这样的索引元素,其实就代表有多少指针,即16384/14=1170
高度为2的B+树能存放1170×16=18720
高度为3的B+树能存放1170×1170×16 = 21902400
InnoDB中B+树高度一般为1-3层,它就能满足千万级的数据存储。
在查找数据时一次页的查找代表一次IO,所以通过主键索引查询通常只需要1-3次IO *** 作即可查找到数据。
MySQL B+树索引和哈希索引的区别:B+树是一个平衡的多叉树,从根节点到每个叶子节点的高度差值不超过1,而且同层级的节点间有指针相互链接。
在B+树上的常规检索,从根节点到叶子节点的搜索效率基本相当,不会出现大幅波动,而且基于索引的顺序扫描时,也可以利用双向指针快速左右移动,效率非常高。
因此,B+树索引被广泛应用于数据库、文件系统等场景。顺便说一下,xfs文件系统比ext3/ext4效率高很多的原因之一就是,它的文件及目录索引结构全部采用B+树索引,而ext3/ext4的文件目录结构则采用Linked list, hashed B-tree、Extents/Bitmap等索引数据结构,因此在高I/O压力下,其IOPS能力不如xfs。
哈希索引就是采用一定的哈希算法,把键值换算成新的哈希值,检索时不需要类似B+树那样从根节点到叶子节点逐级查找,只需一次哈希算法即可立刻定位到相应的位置,速度非常快。
B+树索引和哈希索引的明显区别是:
如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;
从示意图中也能看到,如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;
同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);
哈希索引也不支持多列联合索引的最左匹配规则;
B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题。
谈到索引,大家并不陌生。索引本身是一种数据结构,存在的目的主要是为了缩短数据检索的时间,最大程度减少磁盘 IO。
任何有数据的场景几乎都有索引,比如手机通讯录、文件系统(ext4\xfs\ntfs)、数据库系统(MySQL\Oracle)。数据库系统和文件系统一般都采用 B+ 树来存储索引信息,B+ 树兼顾写和读的性能,最极端时检索复杂度为 O(logN),其中 N 指的是节点数量,logN 表示对磁盘 IO 扫描的总次数。
MySQL 支持的索引结构有四种:B+ 树,R 树,HASH,FULLTEXT。
B 树是一种多叉的 AVL 树。B-Tree 减少了 AVL 数的高度,增加了每个节点的 KEY 数量。
B 树的特性:(m 为阶数:结点的孩子个数最大值)
1. 树中每个节点最多含有 m 个孩子节点 (m>=2);
2. 除根节点和叶子结点外,其他节点的孩子数量 >=ceil(m / 2);
3. 若根节点不是叶子结点,最少有两个孩子
特殊情况:没有孩子的根结点,即根结点为叶子结点,整棵树只有一个根节点;
4. 每个非叶子结点中包含有 n 个关键字信息:(n,P0,K1,P1,K2,P2,......,Kn,Pn) 其中:
Ki (i=1...n) 为关键字,且关键字按顺序升序排序 K(i-1)<Ki
Pi 为指向儿子节点的指针,且指针 P(i-1) 指向的儿子节点里所有关键字均小于 Ki,但都大于 K(i-1)
关键字的个数 n 必须满足:[ceil(m / 2)-1]<= n <= m-1
如果一个结点有 n 个关键字,那么该结点有 n+1 个分支。这 n+1 个关键字按照递增顺序排列
所有叶子结点都出现在同一层,是所有遍历的终点位置
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)