文件索引

来源：互联网发布：专门做淘宝客团队编辑：程序博客网时间：2024/05/01 14:17

一、oracle位图索引：

以下内容主要都是关于oracle 10g位图索引，重点是存储，其它优缺点，查询机制等也略微介绍，概因为存储机制是根基。
内容主要分四个部分：
1）来源于http://blog.chinaunix.net/uid-20687159-id-1894992.html
2）来源于http://blog.sina.com.cn/s/blog_4c6fef63010085m8.html
3）来自oracle官方文档的和其它一些。
4）个人的试验，看位图索引的情况。
------------------------------
要想升入dw等，了解位图索引是必不可少的。
了解位图索引的关键是知道索引的内部结构，知道结果，自然知道它的优缺点，所以了解结构是核心。

一，oracle官方文档
关于位图索引的概要介绍-定义、查询原理、优点、缺点。
这里只是一个笔记，非官方原文，摘取了纲要内容：
1.定义，什么是位图索引：就是用位图表示的索引，oracle对于选择度底的列的每个键值建立一个位图，位图中的每一位可能对应多个列，位图中位等于1表示特定的行含有此位图表示的键值。
2.查询，由于索引是位图，所以很多很多时候可以对这些索引中的位图进行位运算-（and 和 or),这样的速度明显比b树快（某些情况下）。由于位图索引可以存储null，所以可以直接通过位图索引计数（肯定是准确的）。后面提到的有点和位图的计算方式是直接相关的。
3.位图的优点(主要针对dw)：

减少即席查询的相应时间
和其它类型索引比较，真正节约了索引数据空间
即使在非常差的硬件上，也可能会有戏剧化的性能提升
高效的并行DML和LOAD操作。
生成索引的时候更高效，首先是不排序，其次是占用的空间少（索引空间）。
可以通过位图索引直接计数。

4.位图索引的缺点（其它资料），也不好说是缺点

不适合选择度底的列
如果有比较频繁的insert,update等操作，可能导致性能很底下，因为更新索引用的是行锁（可能锁定多行），而不是排它锁。
可能会溢出，索引数据块难于放下整个索引值，这导致低效。

二，http://blog.chinaunix.net/uid-20687159-id-1894992.html
示意图-逻辑分析位图
主要至关了解下位图：

需要注意的是，这只是个示意图，实际上每个位图的位数并非刚好等于记录数，而是会根据情况来分解，否则对于居多的数据而言，位图未免太大了。

三，http://blog.sina.com.cn/s/blog_4c6fef63010085m8.html
深入研究--数据块中如何存储
这是真正的深入了解。
为了省事，暂时不修改原文的样式

一.什么是位图索引
我们目前大量使用的索引一般主要是B*Tree索引,在索引结构中存储着键值和键值的RowID,并且是一一对应的.
而位图索引主要针对大量相同值的列而创建(例如：类别，操作员，部门ID,库房ID等),
索引块的一个索引行中存储键值和起止Rowid,以及这些键值的位置编码,
位置编码中的每一位表示键值对应的数据行的有无.一个位图索引块可能指向的是几十甚至成百上千行数据的位置.

这种方式存储数据,相对于B*Tree索引,占用的空间非常小,创建和使用非常快.

当根据键值查询时,可以根据起始Rowid和位图状态,快速定位数据.
当根据键值做and,or或 in(x,y,..)查询时,直接用索引的位图进行或运算,快速得出结果行数据.
当select count(XX) 时,可以直接访问索引就快速得出统计数据.

创建语法很简单,就是在普通索引创建的语法中index前加关键字bitmap即可,例如:
create bitmap index H病人挂号记录_ix_执行人 on H病人挂号记录(执行人);

二.位图索引的特点
1.Bitmap索引的存储空间
相对于B*Tree索引,位图索引由于只存储键值的起止Rowid和位图,占用的空间非常少.
bitmap的空间占用主要根以下4个因素相关:
a.表的总记录数
b.索引列的键值多少,列的不同值越少,所需的位图就越少.
c.操作的类型,批量插入比单条插入所面的位图要少得多,8i,9i下是这样的,10G则没有这种区别,详见后面的分析.
d.索引列相同键值的物理分布,8i,9i中,不同块上的数据,相同的键值,会建立不同的位图行(段)来表示

注:本文提到的8i,9i,10g,我试验的环境是8.1.7,9.2.0.5,10.2

2.Bitmap索引创建的速度
位图索引创建时不需要排序,并且按位存储,所需的空间也少.
B*Tree索引则在创建时需要排序,定位等操作,速度要慢得多.

3.Bitmap索引允许键值为空
B*Tree索引由于不记录空值,当基于is null的查询时,会使用全表扫描,
而对位图索引列进行is null查询时,则可以使用索引.

4.Bitmap索引对表记录的高效访问
当使用count(XX),可以直接访问索引就快速得出统计数据.
当根据位图索引的列进行and,or或 in(x,y,..)查询时,直接用索引的位图进行或运算,在访问数据之前可事先过滤数据.

5.Bitmap索引对批量DML操作只需进行一次索引
由于通过位图反映数据情况,批量操作时对索引的更新速度比B*Tree索引一行一行的处理快得多.

6.Bitmap索引的锁机制
对于B*Tree索引,insert操作不会锁定其它会话的DML操作.
而位图索引,由于用位图反映数据,不同会话更新相同键值的同一位图段,insert、update、delete相互操作都会发锁定。

对于oracle 8i,9i,单行插入时,由于一个位图行(位图段)只记录8行记录,所以最多锁住相同键值的8行数据的DML操作.
而批量插入时，和10G一样,同一键值只有一个位图行（位图段），所以，相同键值的所有数据的DML操作都会被锁住。

下面，针对8i,9i观察一下锁机制：
SQL> Declare
Begin
For i In 1..9
Loop
Insert Into H病人挂号记录(Id,No,号别,执行人) Values(i,'G000001',1,'张1');
End Loop;
Commit;
End;
/
SQL> delete H病人挂号记录 where id=1;
不提交，另开一个会话，
SQL> delete H病人挂号记录 where id=9;
操作可以进行，没有锁定。
SQL> delete H病人挂号记录 where id=8;
操作等待,由于和另外一个会话操作的记录的位图索引在同一个位图段上（一个位图段最多8行）,所以被锁住了。

三.位图索引的适用场合
1.位图索引是Oracle数据库在7.3版本中加入的,8i,9i企业版和个人版支持,标准版不支持.
2.基于规则的优化器无法使用Bitmap索引
3.适应于有大量重复值的列查询
4.对于8i,9i版本，不适用于单行插入,适用于批量插入的数据,
因为单行插入时，相同键值，每插入8行就会生成一行索引块中的位图段,即使相同的值.
而批量插入时，相同键值只生成一个位图段.
5.由于并发DML操作锁定的是整个位图段的大量数据行，所以位图索引主要是用于OLAP应用,也可以用于OLTP中主要为读操作的表.

关于bitmap的两个参数
SQL> show parameter bitmap;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size integer 1048576
create_bitmap_area_size integer 8388608

其中bitmap_merge_area_size是bitmap索引进行合并操作时使用的内存区域,create_bitmap_area_size是创建时使用的内存区域.
8i,9i中,需要根据bitmap的大小以及常见的使用情况来调整.
9i以上,只需设置pga_aggregate_target的值,Oracle即会自动进和内存的调整.

四.位图索引存储原理
位图索引对数据表的列的每一个键值分别存储为一个位图,Oracle对于不同的版本,不同的操作方式,数据生成均有差别.
对于8i,9i,
下面分3种方式来讨论数据的插入:
a.一次插入一行,插入多行后,一次提交;
b.每插入一行,提交一次;
c.批量插入方式,一次提交;

对于第一种方式,观察位图索引的变化情况.
a.假设插入8行相同键值的数据,如果以每行方式插入,然后一次提交,则会生成8个位图
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(1,'G000001',1,'张1');
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> commit;
Commit complete

SQL> alter system dump datafile 1 block 40028;
System altered

row#0[7847] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 31 --键值'张1'
col 1; len 6; (6): 00 40 9c 54 00 00 --rowid的起始位置
col 2; len 6; (6): 00 40 9c 54 00 07 --rowid的终止位置
col 3; len 2; (2): c8 ff --位图编码
row#1[7802] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 08
col 2; len 6; (6): 00 40 9c 54 00 0f
col 3; len 2; (2): c8 03
row#2[7780] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 40 9c 54 00 08
col 2; len 6; (6): 00 40 9c 54 00 0f
col 3; len 1; (1): 02
row#3[7758] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 33
col 1; len 6; (6): 00 40 9c 54 00 08
col 2; len 6; (6): 00 40 9c 54 00 0f
col 3; len 1; (1): 03
row#4[7736] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 34
col 1; len 6; (6): 00 40 9c 54 00 08
col 2; len 6; (6): 00 40 9c 54 00 0f
col 3; len 1; (1): 04
row#5[7714] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 35
col 1; len 6; (6): 00 40 9c 54 00 08
col 2; len 6; (6): 00 40 9c 54 00 0f
col 3; len 1; (1): 05
----- end of leaf block dump -----

但是,下次再插入一行相同键值的数据时,会自动合并这8行位图为一行位图,并生成一个新的索引位图行存放刚插入行的索引:
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(1,'G000001',1,'张1');
1 row inserted
SQL> commit;
Commit complete
SQL> alter system dump datafile 1 block 40028;
System altered

row#0[7847] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 ff
row#1[7825] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 08
col 2; len 6; (6): 00 40 9c 54 00 0f
col 3; len 1; (1): 00
----- end of leaf block dump -----

b.数据每行提交方式,与上面的情况相似,但有一点不一样,每提交一行,拷贝原来的位图,生成新的位图,并标记原来的位图为已删除,
标记为已删除的位图,只有索引块需要分配新的位图时,才会清除标记为已删除的位图,重用这些空间.

在8i,9i上实验的结果,与ITPUB的<Oracle 数据库性能优化>一书378页一致.
如果1000条相同键值的数据插入,将生成125个包括8条记录的位图行.

c.第三种方式,批量插入数据,insert into H病人挂号记录(Id,No,号别,执行人) select ***方式,
同一键值,只生成一次位图,只有一个位图.

SQL> Insert Into H病人挂号记录(Id,No,号别,执行人)
Select 1,'G000001',1,'张1' From dual
Union All
Select 2,'G000002',1,'张1' From dual
Union All
Select 3,'G000003',1,'张1' From dual
Union All
Select 4,'G000004',1,'张1' From dual
Union All
Select 5,'G000005',1,'张1' From dual
Union All
Select 6,'G000006',1,'张1' From dual
Union All
Select 7,'G000006',1,'张1' From dual
Union All
Select 8,'G000006',1,'张1' From dual
Union All
Select 9,'G000006',1,'张1' From dual;
SQL> commit;
Commit complete
SQL> alter system dump datafile 1 block 40028;
System altered

row#0[8006] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 0f
col 3; len 3; (3): c9 ff 01
row#1[8030] flag: ---D-, lock: 2
col 0; NULL
col 1; NULL
col 2; NULL
col 3; NULL
----- end of leaf block dump -----

所以,位图索引最好采用批量插入方式,这样,每个键值只生成一个位图.而单行数据插入方式,每个键值将每8行数据生成一个位图.

10G的情况,则简单得多.
上面3种方式,相同键值的插入,位图的生成是一样的,只有一个位图,并且,每次提交时,并不会删除以前的位图,而是直接修改对应键值的位图.

每次插入一行数据,插入9行后提交
row#0[7763] flag: ------, lock: 2, len=29
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f2 00 0f
col 3; len 8; (8): f9 e4 d5 dc bc 01 ff 01
----- end of leaf block dump -----

再批量插入9行数据并提交
row#0[7733] flag: ------, lock: 2, len=30
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f2 00 17
col 3; len 9; (9): fa e4 d5 dc bc 01 ff ff 03
----- end of leaf block dump -----

可以看出,10G对位图索引的存储进行了优化,一个键值在索引块中只有一个位图

关于位图索引的一些信息,可以参考:bitmap 的一点探究 http://www.itpub.net/114023.html
注意,其中有些结论并不是完全正确的,可以自己实验证明,另外,该文涉及的实验没有标明Oracle版本,不同的版本,结果有差异.

四、个人试验，性能比较
crmii.tkhxx有记录1281792，其中yyb=7911的记录共有23537条。
原来有索引idx_khxx(yyb,khh,khxm),但oracle不会去使用,具体原因不用深究。
后又建立位图索引:
create bitmap index idx_b_khxx on khxx(yyb) ;

--先看没用索引的
SQL> explain plan for SELECT /*+NO_INDEX (A idx_b_khxx)*/ * FROM CRMII.TKHXX A WHERE YYB=7911
2 /

Explained

SQL> select * from table(dbms_xplan.display)
2 /

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2975641408
---------------------------------------------------------------------------
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       | 27884 | 7107K| 11337   (1)| 00:02:17 |
|* 1 | TABLE ACCESS FULL| TKHXX | 27884 | 7107K| 11337   (1)| 00:02:17 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("YYB"=7911)

13 rows selected

--再看有用索引的
SQL> explain plan for select * from crmii.tkhxx where yyb=7911
2 /

Explained

SQL> select * from table(dbms_xplan.display)
2 /

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1238075174
--------------------------------------------------------------------------------
| Id | Operation                    | Name       | Rows | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |            | 27884 | 7107K| 6862   (1)|
|   1 | TABLE ACCESS BY INDEX ROWID | TKHXX      | 27884 | 7107K| 6862   (1)|
|   2 |   BITMAP CONVERSION TO ROWIDS|            |       |       |            |
|* 3 |    BITMAP INDEX SINGLE VALUE | IDX_B_KHXX |       |       |            |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("YYB"=7911)

15 rows selected
--位图索引就是这么简单，首先更具单个键值找到对应的位图，然后把位图中的值转换为rowid，再根据rowid访问表格
--就以上这个情况来看，效率提升了大约100%


再来学学看看下索引数据的存储情况：
CREATE TABLE TEST.TEST_BITMAP(ID INT,SCORE NUMBER);
CREATE BITMAP INDEX TEST.IDX_B_TEST_BITMAP ON TEST.TEST_BITMAP(ID);
INSERT INTO TEST.TEST_BITMAP VALUES(1,12);
INSERT INTO TEST.TEST_BITMAP VALUES(1,13);
INSERT INTO TEST.TEST_BITMAP VALUES(1,14);
INSERT INTO TEST.TEST_BITMAP VALUES(1,15);
INSERT INTO TEST.TEST_BITMAP VALUES(1,16);
INSERT INTO TEST.TEST_BITMAP VALUES(1,17);
INSERT INTO TEST.TEST_BITMAP VALUES(1,18);
INSERT INTO TEST.TEST_BITMAP VALUES(1,19);
INSERT INTO TEST.TEST_BITMAP SELECT ID+1,SCORE*2 FROM TEST.TEST_BITMAP;
INSERT INTO TEST.TEST_BITMAP SELECT ID+1,LN(SCORE) FROM TEST.TEST_BITMAP;
COMMIT;

SQL> select count(*) from test.test_bitmap
2 /

COUNT(*)
----------
        32

SQL> select header_file,header_block,blocks,bytes from dba_segments where segment_name='IDX_B_TEST_BITMAP' and owner='TEST'
2 /

HEADER_FILE HEADER_BLOCK     BLOCKS      BYTES
----------- ------------ ---------- ----------
        205         1515          8      65536

SQL> ALTER SYSTEM DUMP DATAFILE 205 BLOCK MIN 1515 BLOCK MAX 1522
查看文件：
row#0[7789] flag: ------, lock: 2, len=28
col 0; len 2; (2): c1 02
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 33 40 05 e8 00 07
col 3; len 8; (8): f8 c2 ca 88 f2 a9 02 ff
row#1[7712] flag: ------, lock: 2, len=29
col 0; len 2; (2): c1 03
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 33 40 05 e8 00 17
col 3; len 9; (9): f9 c3 ca 88 f2 a9 02 ff ff
row#2[7664] flag: ------, lock: 2, len=28
col 0; len 2; (2): c1 04
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 33 40 05 e8 00 1f
col 3; len 8; (8): f8 c5 ca 88 f2 a9 02 ff
前文说col 0是可以转为具体的键值，可以通过dbms_stats.convert_raw_value直接转，对于varchar2好像是这样，
但是对于int或者number则不是这样的。这得从数值的存储方式说起，有关数值存储可以看 http://www.linuxidc.com/Linux/2011-01/31375.htm
col 0; len 2; (2): c1 02
这里c1转为10进制=to_number('c1','xxxx')=193, 02就是2 ，结果和dump(1)的 “Typ=2 Len=2: 193,2”后面相等，不过少了长度和类型。

二、如果读者对B树索引感兴趣，请参考这篇博客《数据搜索和数据库索引》

0 0