简述Oracle IOT（Index Organized Table）

时间 2019-11-12

标签简述 oracle iot index organized table 栏目 Oracle 繁體版

原文原文链接

转：http://blog.itpub.net/17203031/viewspace-744477数据库

对关系型数据库产品（RDBMS）而言，一个重要特性就是：数据信息都被组织为二维数据表，信息的表达能够经过一系列的关联（Join）来完成。具体数据库产品在实现这个标准的时候，又有千差万别的特色。就是一个特定的数据库RDBMS产品，每每也提供不一样的实现方法。ide

一、从堆表（Heap Table）到索引组织表（Index Organization Table）性能

Oracle做为一款成熟的数据库软件产品，就提供了多种数据表存储结构。咱们最多见的就是三种，分别为堆表（Heap Table）、索引组织表（Index Organization Table，简称为IOT）和聚簇表（Cluster Table）。spa

Heap Table是咱们在Oracle中最常使用的数据表，也是Oracle的默认数据表存储结构。在Heap Table中，数据行是按照“随机存取”的方式进行管理。从段头块以后，一直到高水位线一下的空间，Oracle都是按照随机的方式进行“粗放式”管理。当一条数据须要插入到数据表中时，默认状况下，Oracle会在高水位线如下寻找有没有空闲的地方，可以容纳这个新数据行。若是能够找到这样的地方，Oracle就将这行数据放在空位上。注意，这个空位选择彻底依“能放下”的原则，这个空位多是被删除数据行的覆盖位。.net

若是Heap Table段的HWM下没有找到合适的位置，Oracle堆表才去向上推高水位线。在数据行存储上，Heap Table的数据行是彻底没有次序之分的。咱们称之为“随机存取”特征。orm

对Heap Table，索引独立段的添加通常能够有效的缓解因为随机存取带来的检索压力。Index叶子节点上记录的数据行键值和Rowid取值，可让Server Process直接定位到数据行的块位置。对象

聚簇（Cluster Table）是一种合并段存储的状况。Oracle认为，若是一些数据表更新频率不高，可是常常和另一个数据表进行链接查询（Join）显示，就能够将其组织在一个存储结构中，这样能够最大限度的提高性能效率。对聚簇表而言，多个数据表按照链接键的顺序保存在一块儿。blog

一般系统环境下，咱们使用Cluster Table的状况不太多。Oracle中的数据字典大量的使用聚簇。相比是各类关联的基表之间固定链接检索的场景较多，从而肯定的方案。索引

最后就是本系列的IOT（Index Organization Table）。同Cluster Table同样，IOT是在Oracle数据表策略的一种“非主流”，应用的场景比较窄。可是一些状况下使用它，每每能够起到很是好的效果。产品

简单的说，IOT区别于堆表的最大特色，就在于数据行的组织并非随机的，而是依据数据表主键，按照索引树进行保存。从段segment结构上看，IOT索引段就包括了全部数据行列，不存在单独的数据表段。

IOT在保存结构上有一些特殊之处，应用在一些特殊的场景之下。本系列将逐个分析IOT的一些特征，最后讨论咱们究竟在什么样的场景下，能够选择IOT做为数据表方案。

二、IOT基础

在建立使用IOT上，咱们要强调Primary Key的做用。对通常的堆表而言，Primary Key是无关紧要的。一种说法是：当一个堆表没有设置主键的时候，rowid伪列就是对应的主键值。并且，Primary Key能够在数据表建立以后进行追加设置。

可是，IOT对于主键的设置格外严格，要求建立表的时候就必须指定明确的主键列。下面咱们经过一系列的实验来证实，实验环境为Oracle 11g。

SQL> select * from v$version;

BANNER

------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE 11.2.0.1.0 Production

咱们使用相同的结构，来建立出IOT和Heap Table对照。

--不指定主键，是没法建立IOT；

SQL> create table m (id number) organization index;

create table m (id number) organization index

ORA-25175: 未找到任何 PRIMARY KEY 约束条件

在create table语句后面使用organization index，就指定数据表建立结构是IOT。可是在不指定主键Primary Key的状况下，是不容许建表的。

SQL> create table t_iot (object_id number(10) primary key, object_name varchar2(100)) organization index;

Table created

SQL> create table t_heap (object_id number(10) primary key, object_name varchar2(100));

Table created

（插入相同数据来源行……）

SQL> exec dbms_stats.gather_table_stats(user,'T_IOT',cascade => true);

PL/SQL procedure successfully completed

SQL> exec dbms_stats.gather_table_stats(user,'T_HEAP',cascade => true);

PL/SQL procedure successfully completed

从数据字典的层面上，咱们分析一下两个数据表的差别，一窥IOT的特色。

SQL> select table_name, tablespace_name, blocks, num_rows from user_tables where table_name in ('T_IOT','T_HEAP');

TABLE_NAME TABLESPACE_NAME BLOCKS NUM_ROWS

------------------------------ ------------------------ ---------- ----------

T_HEAP SYSTEM 157 72638

T_IOT 72638

SQL> select segment_name, blocks, extents from user_segments where segment_name in ('T_IOT','T_HEAP');

SEGMENT_NAME BLOCKS EXTENTS

-------------------- ---------- ----------

T_HEAP 256 17

上面两句SQL揭示了几个问题。首先，Oracle认可IOT是一个数据表，而且统计了数据行数。可是对数据表的存储表空间和大小没有明确的说明，user_tables视图中这部分的内容为空。

其次，从段结构来看，Oracle明确不认可存在T_IOT段。由于若是有段segment对象，就意味有空间分配。可是数据表有数据，是存放在哪里呢？

咱们知道，给数据表添加索引的时候，Oracle会自动的添加一个惟一索引。那么咱们去检查一下这部分的结构状况。

SQL> select index_name, index_type, table_name, PCT_THRESHOLD, CLUSTERING_FACTOR from user_indexes where table_name in ('T_IOT','T_HEAP');

INDEX_NAME INDEX_TYPE TABLE_NAME PCT_THRESHOLD CLUSTERING_FACTOR

-------------------- -------- ---------- ------------- -----------------

SYS_C0012408 NORMAL T_HEAP 256

SYS_IOT_TOP_75124 IOT - TOP T_IOT 50 0

SQL> select segment_name, blocks, extents from user_segments where segment_name in ('SYS_C0012408','SYS_IOT_TOP_75124');

SEGMENT_NAME BLOCKS EXTENTS

-------------------- ---------- ----------

SYS_C0012408 256 17

SYS_IOT_TOP_75124 256 17

索引段是存在的，并且明确标注索引类型为IOT索引。这说明几个问题：

首先，对于IOT而言，只有索引段，没有数据段。通常的索引而言，叶子节点上只有索引列的取值和rowid。而对于IOT而言，主键索引上对应就是数据行和索引列取值。

其次，IOT的溢出段阈值（PCT_THRESHOLD）。这是Oracle IOT的特殊策略。简单的说，当咱们把所有数据行保存在叶子节点上，一旦发生主键值的变化、新值插入、删除等动做，索引叶子块的分裂动做是频繁的。数据行保存在叶子节点上只会让这样的分裂动做更加频繁和后果严重。Oracle提出将一部分的非主键列单独存储，这个参数就是比例值。

最后，咱们探讨一下IOT索引的Clustering Factor。Clustering Factor是反映索引叶子节点顺序和数据保存行直接离散程度的综合性指标。通常来讲，堆表的Clustering Factor是随着DML操做不断退化的过程。Clustering Factor是影响到Oracle索引路径成本的一个重要参数（http://space.itpub.net/17203031/viewspace-680936），会影响到CBO的成本决策。 IOT的索引这部分的值永远为0，由于索引的顺序就是数据行的顺序，二者存储顺序相同，绝对一致。

三、IOT与执行计划

在IOT数据表下，咱们一般的执行计划会如何呢？普通Heap Table和IOT在这部分的差别很大。

一般而言，Heap Table的索引路径伴随着两次段结构的读取——索引段和数据段。先读取索引段段头，经历根节点、分支节点、叶子节点，最后获取到结果集合rowid列表。以后进行回表操做，使用rowid依次查询数据表的行。

可是IOT表能够不一样。索引和数据保留在一块儿，理论上拿到了叶子节点，也就是拿到了数据行。IOT是不存在回表操做的，因此相对heap table来讲，回表部分红本是节省的。

下面咱们经过执行计划，来看IOT的特征。

SQL> explain plan for select * from t_iot where object_id=1000;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

---------------------------------------------------------------------------

Plan hash value: 2277898128

--------------------------------------------------------------------------

---------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 11 | 1 (0)| 00:

|* 1 | INDEX UNIQUE SCAN| SYS_IOT_TOP_75124 | 1 | 11 | 1 (0)| 00:

-------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("OBJECT_ID"=1000)

13 rows selected

SQL> explain plan for select * from t_iot;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

-------------------------------------------------------------------------------

Plan hash value: 4201110863

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 72638 | 780K| 47 (0)|

| 1 | INDEX FAST FULL SCAN| SYS_IOT_TOP_75124 | 72638 | 780K| 47 (0)|

------------------------------------------------------------------------

8 rows selected

对于IOT，咱们要保证访问的数据表的方式是主键路径为主。在上面的两个执行计划中，咱们按照主键进行检索，路径为Index Unique Scan。全表扫描为Index Fast Full Scan。二者都没有明显的回表动做。

试想，若是数据表较小，Index Full Scan也是IOT表经常出现的执行路径。

对通常的Heap Table，执行路径如何呢？

SQL> explain plan for select * from t_heap where object_id=1000;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

----------------------------------------------------------------------------

Plan hash value: 1833345710

-----------------------------------------------------------------------------

---------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 11 | 2 (0)

| 1 | TABLE ACCESS BY INDEX ROWID| T_HEAP | 1 | 11 | 2 (0)

|* 2 | INDEX UNIQUE SCAN | SYS_C0012408 | 1 | | 1 (0)

--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("OBJECT_ID"=1000)

14 rows selected

SQL> explain plan for select * from t_heap;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

---------------------------------------------------------------------------

Plan hash value: 1253663840

---------------------------------------------------------------------------

----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 72638 | 780K| 42 (0)| 00:00:01 |

| 1 | TABLE ACCESS FULL| T_HEAP | 72638 | 780K| 42 (0)| 00:00:01 |

----------------------------------------------------------------------------

8 rows selected

普通堆表都不能避免出现回表动做。

最后，咱们要声明一下回表动做的成本影响。IOT和Heap Table一个很大的执行计划差别，就是回表。可是从成本上计算，CBO并非由于回表动做才肯定执行计划，而是Clustering Factor的影响。

对堆表而言，Clustering Factor都是一个很大的问题，不管是CBO的成本公式上，仍是不断Degrade的前景。IOT一个突出优点就是直接消灭了Clustering Factor的成本因素。

可是这也就带来一个问题，一个数据表只能按照主键的顺序进行组织，辅助索引（Secondary Index）的问题是不少版本Oracle和IOT使用者争议的话题。Secondary Index问题咱们在后面会继续讨论到。

下篇中咱们会继续讨论有关IOT维护等其余内容。