B树索引分裂

一、索引分裂

1.  什么是分裂

在开始介绍之前,我们先来搞清楚什么是索引分裂吧。“索引分裂”就是索引块的分裂,当一次DML事务操作修改了索引块上的数据,但是旧有的索引块没有足够的空间来容纳新修改的数据,那么将分裂出一个新索引块,旧有块的部分数据放到新开辟的索引块上去,这个过程就称为索引块的分裂(INDEX BLOCK SPLIT)。

如图1所示,当有新值插入到L4叶节点块的时候,此时L4叶节点块是“充满”状态,已经没有足够的空间来存储新值了,此时会在B2分支节点下,分裂出一个新的叶节点L5来存储新值。如果分支节点B2也是“充满”了呢?那就要进行分支节点的分裂,即在ROOT根节点下,分裂出一个新的分支节点出来。依此类推,如果根节点也“充满”了,则需要进行根节点的分裂。如果发生了根节点的分裂,也意味着B树的高度(BTREE LEVEL)增加了一个层次。对真正意义上的树来说,这种生长是好事,但对B树索引来说,这就不是什么好事情了,B树索引的高度需要严格控制的。

图1  新值产生索引分裂

2.  分裂的类型

从上面的介绍来说,我们大致可以将索引分裂归为三种类型:根节点分裂、分支节点分裂、叶节点分裂。当然,也可以说是两种类型,因为根节点分裂实质上一种特殊的分支节点分裂。我们首要需要关注的是其中叶节点的分裂,因为它是最频繁发生,对性能影响最直接的因素。

我们说过分裂出新节点后,会将一部分旧有的数据放到新节点上去,按照数据迁移量的比例,我们又可以将索引分裂分为两种类型:9-1分裂和5-5分裂。如果叶节点和分支节点同时发生分裂,其分裂比例的类型是相同的,即要么都是9-1分裂,要么都是5-5分裂。

q  9-1分裂:绝大部分数据还保留在旧有节点上,仅有非常少的一部分数据迁移到新节点上。

q  5-5分裂:旧节点和新节点上的数据比例几乎是持平的。

我们通常所说的索引分裂,大部分情况都指的是9-1的分裂。当事务向索引的最右侧的叶节点上插入一条大于或等于现有索引块上最大值的数据,且该索引块上不存在其他未提交的事务,如果没有足够的空间,就会发生9-1分裂。

很遗憾的是,当发生左侧节点上插入数据的时候,发生9-1分裂就会出现一些问题。如图2所示,当向左侧分支节点插入新值,即使其兄弟右侧分支节点数据区中没有数据(或者说没有右节点),它们的父节点都会发生分裂,极端情况下甚至会促使B树的高度增长,这对索引性能来说是很悲剧的,这一缺陷在10g以前的版本中都是存在的。

图2  左节点9-1分裂

从Oracle 10g开始,对于左侧节点的数据插入行为,引进了5-5分裂的方式,修正了9-1分裂造成的缺陷。如图3所示,当左侧分支节点B1已经“充满”状态,会去判断其兄弟右侧分支节点B2是否有空间,如果有,则将部分数据(5:5的比例)迁移到右侧分支节点上,这样就避免了分支节点甚至根节点的分裂。

图3  左节点5-5分裂

5-5分裂的方式也不是万能的,如果过于频繁的5-5分裂也会造成索引空间使用率不高,使得索引结构看上去像一个“虚胖子”,不够“结实’,同样会造成性能问题。

那什么时候会发生5-5分裂呢?简单地来说就是在索引需要分裂,但不能进行9-1分裂的时候就会触发5-5分裂。这听起来像一句废话,可将9-1分裂的条件反过来看,也正是5-5分裂发生的条件:

q  左侧节点发生新值插入时(新值小于索引中的最大值);

q  发生DML操作,索引块上没有足够空间分配新的ITL槽;

q  新值待插入的索引块上存在其他未提交的事务。

对比一下9-1分裂和5-5分裂的发生场景。9-1分裂通常是索引的键值是递增的,表上的事务并发量比较低,可保证新的数据块上有较大的空闲空间插入新值。5-5分裂通常是表上的事务并发度较高,操作的数据是无序的,需保证分裂的新旧数据块上有相对较大的空闲空间以容纳新事务的操作。

总体来看,不论是9-1分裂还是5-5分裂,对于性能来说,都不是什么好事。索引块的分裂意味着索引数据一定范围上的重组,其维护代价都是非常高昂的,应该尽可能地避免不必要的分裂发生。

时间: 2024-10-16 17:42:34

B树索引分裂的相关文章

B树索引

B-Tree索引是最常见的索引结构,默认创建的索引就是B-Tree索引. 一.B树索引的结构 B-树索引是基于二叉树结构的.B-树索引结构有3个基本组成部分:根节点.分支节点和叶子节点.其中根节点位于索引结构的最顶端,而叶子节点位于索引结构的最底端,中间为分子节点.     叶子节点(Leaf node):包含条目直接指向表里的数据行.     分支节点(Branch node):包含的条目指向索引里其他的分支节点或者是叶子节点.     根节点(Branch node):一个B树索引只有一个根

Oracle 基础篇 --- B树索引内部结构

内部结构 将B树索引转储成树状结构的形式而呈现出来: alter session set events 'immediate trace name treedump level INDEX_OBJECT_ID'; SQL> alter session set events 'immediate trace name treedump level 126545'; Session altered. [[email protected] trace]$ pwd /home/oracle/app/or

MySQL的B树索引与索引优化

MySQL的MyISAM.InnoDB引擎默认均使用B+树索引(查询时都显示为"BTREE"),本文讨论两个问题: 为什么MySQL等主流数据库选择B+树的索引结构? 如何基于索引结构,理解常见的MySQL索引优化思路? 为什么索引无法全部装入内存 索引结构的选择基于这样一个性质:大数据量时,索引无法全部装入内存. 为什么索引无法全部装入内存?假设使用树结构组织索引,简单估算一下: 假设单个索引节点12B,1000w个数据行,unique索引,则叶子节点共占约100MB,整棵树最多20

浅谈MySQL的B树索引与索引优化

前言 MySQL的MyISAM.InnoDB引擎默认均使用B+树索引(查询时都显示为"BTREE"),本文讨论两个问题: 为什么MySQL等主流数据库选择B+树的索引结构? 如何基于索引结构,理解常见的MySQL索引优化思路? 索引结构的选择基于这样一个性质:大数据量时,索引无法全部装入内存. 为什么索引无法全部装入内存? 假设使用树结构组织索引,简单估算一下: 假设单个索引节点12B,1000w个数据行,unique索引,则叶子节点共占约100MB,整棵树最多200MB. 假设一行数

MySQL之B+树索引(转自掘金小册 MySQL是怎样运行的,版权归作者所有!)

每个索引都对应一棵B+树,B+树分为好多层,最下边一层是叶子节点,其余的是内节点.所有用户记录都存储在B+树的叶子节点,所有目录项记录都存储在内节点. InnoDB存储引擎会自动为主键(如果没有它会自动帮我们添加)建立聚簇索引,聚簇索引的叶子节点包含完整的用户记录. 我们可以为自己感兴趣的列建立二级索引,二级索引的叶子节点包含的用户记录由索引列 + 主键组成,所以如果想通过二级索引来查找完整的用户记录的话,需要通过回表操作,也就是在通过二级索引找到主键值之后再到聚簇索引中查找完整的用户记录. B

Mysql之B+树索引实战

索引代价 空间上的代价 一个索引都对应一棵B+树,树中每一个节点都是一个数据页,一个页默认会占用16KB的存储空间,所以一个索引也是会占用磁盘空间的. 时间上的代价 索引是对数据的排序,那么当对表中的数据进行增.删.改操作时,都需要去维护修改内容涉及到的B+树索引.所以在进行增.删.改操作时可能需要额外的时间进行一些记录移动,页面分裂.页面回收等操作来维护好排序. B+树索引实战 以下示例是如下数据: CREATE TABLE t1( a int PRIMARY KEY, b INT, c IN

mysql 学习 - B+树索引

我们已经知道在单一数据页中查找数据时, 如果查找条件是主键的话, 可以使用二分法定位槽, 然后顺序遍历槽中的数据查找指定数据. 但是我们并不知道如何在数以万计的页中定位数据在哪个页中, 在没有索引的情况下,不论是根据主键列或者其他列的值进行查找,由于我们并不能快速的定位到记录所在的页,所以只能从第一个页沿着双向链表一直往下找,在每一个页中根据我们刚刚唠叨过的查找方式去查找指定的记录. 简单索引介绍 为了能够快速定位数据在哪个页中, 索引规定, 下一个数据页中用户记录的主键值必须大于上一个页中用户

mysql B+树索引简述

一,查询B+树索引的流程 B+树索引找到叶节点,再找到对应的数据页,然后将数据页加载到内存中,通过二分查找Page Directory中的槽,查找出一个粗略的目录,然后根据槽的指针指向链表中的行记录,之后在链表中依次查找. 需要注意的地方是,B+树索引不能找到具体的一条记录,而是只能找到对应的页.把页从磁盘装入到内存中,再通过Page Directory进行二分查找,同时此二分查找也可能找不到具体的行记录(有可能会找到),只是能找到一个接近的链表中的点,再从此点开始遍历链表进行查找. 二,聚簇索

B树索引和位图索引的区别!

B树索引主键和唯一性约束字段的B树索引,效率几乎和海量数据没有关系. 键值重复率低的字段比较适合使用B树索引. 位图索引键值重复率高的字段比较适合使用位图索引.count.and.or.in这些特定的操作更适合位图索引. DML操作比较多的表不适合使用位图索引. 复合索引在where条件中必须带驱动列,复合索引才会使用. 键值重复率低(DISTINCT数量多)的字段放在前面. 用实验说明为什么位图索引不适合OLTP,比较适合OLAP.即:DML操作比较多的表不适合使用位图索引. 首先创建测试表: