[20160711]索引键值在Btree索引块中的顺序3

[20160711]索引键值在B tree索引块中的顺序3.txt

--上午测试索引键值在B tree索引块中的顺序,许多人认为是有序,主要是插入后再建立索引.
--这样看到索引块里面的键值就是有序的.

--今天测试一下,如果索引分裂后是否会排序呢?索引分裂有两种情况,前面测试leaf node 50-50 splits的情况.
--继续测试leaf node 90-10 splits的情况.

测试看看.

1.环境:
SCOTT@test01p> @ ver1
PORT_STRING                    VERSION        BANNER                                                                               CON_ID
------------------------------ -------------- -------------------------------------------------------------------------------- ----------
IBMPC/WIN_NT64-9.1.0           12.1.0.1.0     Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0

create table t (x varchar2(10));
insert into t select lpad(rownum,6,'0') from dual connect by level<=500;
commit ;
create index i_t_x on t(x) pctfree 0;

SCOTT@test01p> select header_file,header_block from dba_segments where owner='SCOTT' and segment_name='I_T_X';
HEADER_FILE HEADER_BLOCK
----------- ------------
          9          178
--//dba=9,179 就是索引的root节点.
SCOTT@test01p> select OWNER ,OBJECT_NAME, OBJECT_ID,DATA_OBJECT_ID from dba_objects where owner=user and object_name='I_T_X';
OWNER  OBJECT_NAME           OBJECT_ID DATA_OBJECT_ID
------ -------------------- ---------- --------------
SCOTT  I_T_X                    105144         105144

SCOTT@test01p> alter session set events 'immediate trace name treedump level 105144';
Session altered.

----- begin tree dump
branch: 0x24000b3 37748915 (0: nrow: 2, level: 1)
   leaf: 0x24000b4 37748916 (-1: nrow: 444 rrow: 444)
   leaf: 0x24000b5 37748917 (0: nrow: 56 rrow: 56)
----- end tree dump

--很明显一个数据块能插入444条键值.重新插入看看.
SCOTT@test01p> truncate table t;
Table truncated.

--//按照顺序插入:
SCOTT@test01p> insert into t  select * from (select lpad(rownum,6,'0') a from dual connect by level<=888 ) ;
888 rows created.

SCOTT@test01p> commit ;
Commit complete.

insert into t values('000889');
commit;

SCOTT@test01p> insert into t  select * from (select lpad(rownum+889,6,'0') a from dual connect by level<=443 order by DBMS_RANDOM.RANDOM) ;
443 rows created.

SCOTT@test01p> commit ;
Commit complete.

2.检查转储内容:
SCOTT@test01p> alter system checkpoint ;
System altered.

SCOTT@test01p> alter session set events 'immediate trace name treedump level 105144';
Session altered.

----- begin tree dump
branch: 0x24000b3 37748915 (0: nrow: 3, level: 1)
   leaf: 0x24000b5 37748917 (-1: nrow: 444 rrow: 444)
   leaf: 0x24000b6 37748918 (0: nrow: 444 rrow: 444)
   leaf: 0x24000b7 37748919 (1: nrow: 444 rrow: 444)
----- end tree dump

SCOTT@test01p> @ dfb16 0x24000b7
    RFILE#     BLOCK# TEXT
---------- ---------- ------------------------------------------------------------
         9        183 alter system dump datafile 9 block 183 ;

SCOTT@test01p> alter system dump datafile 9 block 183 ;
System altered.

...
026136C00 00000000 00000000 30060200 39383030  [...........00089]
026136C10 40020633 0F008B00 30060200 39383030  [3..@.......00089]
026136C20 40020634 15008B00 30060200 39383030  [4..@.......00089]
026136C30 40020635 58008B00 30060200 39383030  [5..@...X...00089]
026136C40 40020636 59008B00 30060200 39383030  [6..@...Y...00089]
026136C50 40020637 01008B00 30060200 39383030  [7..@.......00089]
026136C60 40020638 05008B00 30060200 30393030  [8..@.......00090]
026136C70 40020630 57028F00 30060200 30393030  [0..@...W...00090]
026136C80 40020632 11008B00 30060200 30393030  [2..@.......00090]
026136C90 40020633 79008B00 30060200 30393030  [3..@...y...00090]
...

--明显没有排序.

3.插入数据看看:
SCOTT@test01p> select max(x) from t;
MAX(X)
----------
001332

--444*3+1=1333

SCOTT@test01p> select * from t where x='001333';
no rows selected

--//注意插入'001333',是最大值,这个时候索引分裂是90-10.
SCOTT@test01p> select a.*,b.name from v$mystat a , v$statname b where a.statistic#=b.statistic# and b.name like 'leaf%';
       SID STATISTIC#      VALUE     CON_ID NAME
---------- ---------- ---------- ---------- ----------------------------------------
       130        572          0          0 leaf node splits
       130        574          0          0 leaf node 90-10 splits

SCOTT@test01p> insert into t values('001333');
1 row created.

SCOTT@test01p> commit ;
Commit complete.

SCOTT@test01p> select a.*,b.name from v$mystat a , v$statname b where a.statistic#=b.statistic# and b.name like 'leaf%';
       SID STATISTIC#      VALUE     CON_ID NAME
---------- ---------- ---------- ---------- ----------------------------------------
       130        572          1          0 leaf node splits
       130        574          1          0 leaf node 90-10 splits

--可以发现发生了索引分裂,并且leaf node splits增加1,而leaf node 90-10 splits=1.说明90-10分裂.
--这种分裂实际上原来的100:1条记录的分裂.并不是90-10分裂.

SCOTT@test01p> alter system checkpoint ;
System altered.

SCOTT@test01p> alter session set events 'immediate trace name treedump level 105144';
Session altered.

----- begin tree dump
branch: 0x24000b3 37748915 (0: nrow: 4, level: 1)
   leaf: 0x24000b5 37748917 (-1: nrow: 444 rrow: 444)
   leaf: 0x24000b6 37748918 (0: nrow: 444 rrow: 444)
   leaf: 0x24000b7 37748919 (1: nrow: 444 rrow: 444)
   leaf: 0x24000b4 37748916 (2: nrow: 1 rrow: 1)
----- end tree dump

SCOTT@test01p> set verify off
SCOTT@test01p> @ dfb16  0x24000b7
    RFILE#     BLOCK# TEXT
---------- ---------- ------------------------------------------------------------
         9        183 alter system dump datafile 9 block 183 ;

--//分别转储看看.
alter system dump datafile 9 block 183 ;

...
020C36400 00000000 00000000 30060000 38383030  [...........00088]
020C36410 40020639 1B018F00 30060000 39383030  [9..@.......00089]
020C36420 40020630 46018F00 30060000 39383030  [0..@...F...00089]
020C36430 40020631 3B018F00 30060000 39383030  [1..@...;...00089]
020C36440 40020632 B2018F00 30060000 39383030  [2..@.......00089]
020C36450 40020633 0F008B00 30060000 39383030  [3..@.......00089]
020C36460 40020634 15008B00 30060000 39383030  [4..@.......00089]
020C36470 40020635 58008B00 30060000 39383030  [5..@...X...00089]
020C36480 40020636 59008B00 30060000 39383030  [6..@...Y...00089]
020C36490 40020637 01008B00 30060000 39383030  [7..@.......00089]
020C364A0 40020638 05008B00 30060000 39383030  [8..@.......00089]
020C364B0 40020639 A3018F00 30060000 30393030  [9..@.......00090]
020C364C0 40020630 57028F00 30060000 30393030  [0..@...W...00090]
020C364D0 40020631 1D018F00 30060000 30393030  [1..@.......00090]
020C364E0 40020632 11008B00 30060000 30393030  [2..@.......00090]
020C364F0 40020633 79008B00 30060000 30393030  [3..@...y...00090]
020C36500 40020634 5A018F00 30060000 30393030  [4..@...Z...00090]
020C36510 40020635 04008B00 30060000 30393030  [5..@.......00090]
...

--//可以发现分裂后索引键值是排序的.也许是许多人看索引块键值是排序的原因.

时间： 2024-08-14 19:51:46

[20160711]索引键值在Btree索引块中的顺序3的相关文章

[20160711索引键值在B tree索引块中的顺序2

[20160711]索引键值在B tree索引块中的顺序2.txt --上午测试索引键值在B tree索引块中的顺序,许多人认为是有序,主要是插入后再建立索引. --这样看到索引块里面的键值就是有序的. --今天测试一下,如果索引分裂后是否会排序呢?索引分裂有两种情况,先测试leaf node 50-50 splits的情况. 测试看看. 1.环境: SCOTT@test01p> @ ver1 PORT_STRING                    VERSION        BANNE

[20111223]索引键值在B tree索引块中的顺序.txt

[20111223]索引键值在B tree索引块中的顺序.txt 参考链接:http://www.adellera.it/blog/2009/05/24/order-keys-inside-index-blocks/ 自己为了加强理解重复一下对方的测试! 1.建立测试表以及索引 SQL> select * from v$version; BANNER -------------------------------------------------------------------------

非分区键的GLOBAL分区索引键值更新会造成麻烦吗？

我们都知道如果想修改分区表的分区键的值如果跨越了分区,那么必须加入ENABLE ROW MOVEMENT 进行,因为此时可能的ROWID会出现变动, 关于ROWID 如下: Object ID (4 bytes) + DBA (4 bytes) + Row (2 bytes) 其中DBA包含了BLOCK地址和DATAFILE地址,如果UPDATE分区键的记录,可能的DATAFILE和BLOCK 都需要变动,所以要开启ENABLE ROW MOVEMENT. 而修改分区索引的键值在多个分区中移动为

php数组索引与键值操作技巧实例分析_php技巧

本文实例讲述了php数组索引与键值操作技巧.分享给大家供大家参考.具体如下: <?php $array = array("a", "b","c"); //定义数组 $array[] = "Simon"; //增加一个新的数组元素 print_r($array); //输出数组 ?> <?php $array = array("a", "b","c")

php获取数组中键值最大数组项的索引值[原创]_php技巧

本文实例讲述了php获取数组中键值最大数组项的索引值的方法.分享给大家供大家参考.具体分析如下: 一.问题: 从给定数组中获取值最大的数组项的键值.用途如:获取班级得分最高的学生的姓名. 二.解决方法: <?php /* * Created on 2015-3-17 * Created by www.jb51.net */ $arr=array('tom'=>9,'jack'=>3,'kim'=>5,'hack'=>4); asort($arr); //print_r($ar

索引数据块中出现热块及Latch的场景示例

索引的热块其实和数据块的热块发生的原理大相径庭,也都是因为大量会话一起访问同一个索引块造成的,我们的解决方案有反向索引,分区索引等.我们说任何一种方式都不是完美的,有优点就必然有缺点,我们把包含索引键值的索引块从顺序排列打散到无序排列,降低了latch争用,同时也增加了oracle扫描块的数量.我们在实际使用时多测试取长补短,以提高系统的整体性能为目标. LEO1@LEO1>create table leo1 (id  number , name  varchar2(200));     创建了

MySQL的btree索引和hash索引的区别

hash 索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引.       可能很多人又有疑问了,既然 Hash 索引的效率要比 B-Tree 高很多,为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢?任何事物都是有两面性的,Hash 索引也一样,虽然 Hash 索引效率高,但是 Hash 索引本身由于其特殊性也带来了很多限制和弊

[数据库]MySQL Hash索引和B-Tree索引的区别

MySQL Hash索引和B-Tree索引的区别究竟在哪里呢?相信很多人都有这样的疑问,下文对两者的区别进行了详细的分析,供您参考. MySQL Hash索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引.  可 能很多人又有疑问了,既然 Hash 索引的效率要比 B-Tree 高很多,为什么大家不都用 Hash 索引而还要使用 B-Tree 索

MySQL Hash索引和B-Tree索引的区别_Mysql

MySQL Hash索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引. 可 能很多人又有疑问了,既然 Hash 索引的效率要比 B-Tree 高很多,为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢?任何事物都是有两面性的,Hash 索引也一样,虽然 Hash 索引效率高,但是 Hash 索引本身由于其特殊性也带来了很多限制和弊