資料庫表--index organized table

索引組織表(IOT)不僅可以儲存資料，還可以儲存為表建立的索引。索引組織表的資料是根據主鍵排序後的順序進行排列的，這樣就提高了訪問的速度。但是這是由犧牲插入和更新效能為代價的(每次寫入和更新後都要重新進行重新排序)。

JEL@JEL >create table iot_addr (empno references emp(empno) on delete cascade,addr varchar2(10),primary key (empno,addr)) organization index;
JEL@JEL >select dbms_metadata.get_ddl('TABLE','IOT_ADDR') FROM DUAL;

DBMS_METADATA.GET_DDL('TABLE','IOT_ADDR')
--------------------------------------------------------------------------------

  CREATE TABLE "JEL"."IOT_ADDR"
   (    "EMPNO" NUMBER,
        "ADDR" VARCHAR2(10),
         PRIMARY KEY ("EMPNO", "ADDR") ENABLE,
         FOREIGN KEY ("EMPNO")
          REFERENCES "JEL"."EMP" ("EMPNO") ON DELETE CASCADE ENABLE
   ) ORGANIZATION INDEX NOCOMPRESS PCTFREE 10 INITRANS 2 MAXTRANS 255 LOGGING
  STORAGE(INITIAL 2097152 NEXT 2097152 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "JEL"

DBMS_METADATA.GET_DDL('TABLE','IOT_ADDR')
--------------------------------------------------------------------------------
 PCTTHRESHOLD 50

注意兩點：

    ● 建立IOT時，必須要設定主鍵，否則報錯。

    ● 索引組織表實際上將所有資料都放入了索引中。

NOCOMPRESS--oracle把每個值分別儲存在各個索引條目中。如果物件的主鍵在A、B和C列上，A、B和C的每一次出現都會物理的儲存。反過來是compress N，這裡N是一個整數，表示壓縮的列數。這樣可以避免重複值，這樣在A的值重複出現時，將不再物理的儲存他們。這不會降低併發性，可能顯著的減少I/O，並允許更多的資料在緩衝區中快取，原因是每個塊中能有更多的資料。測試如下：
JEL@JEL >create table iot (owner,object_type,object_name,constraint iot_pk primary key(owner,object_type,object_name)) organization index nocompress as select distinct owner,object_type,object_name from all_objects;

Table created.
JEL@JEL >analyze index iot_pk validate structure;

Index analyzed.

JEL@JEL >select lf_blks,br_blks,used_space,opt_cmpr_count,opt_cmpr_pctsave from index_stats;

   LF_BLKS    BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
        44          1     310167              2               34

JEL@JEL >alter table iot move compress 1;

Table altered.

JEL@JEL >analyze index iot_pk validate structure;

Index analyzed.

JEL@JEL >select lf_blks,br_blks,used_space,opt_cmpr_count,opt_cmpr_pctsave from index_stats;

   LF_BLKS    BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
        37          1     265135              2               23

JEL@JEL >alter table iot move compress 2;

Table altered.

JEL@JEL >analyze index iot_pk validate structure;

Index analyzed.

JEL@JEL >select lf_blks,br_blks,used_space,opt_cmpr_count,opt_cmpr_pctsave from index_stats;

   LF_BLKS    BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
        29          1     203386              2                0


overflow--因為所有資料都放入索引，所以當表的資料量很大時，會降低索引組織表的查詢效能。此時設定溢位段將主鍵和溢位資料分開來儲存以提高效率。如果IOT的行資料變得太大，就可以溢位到另外的段。構成主鍵的列不能溢位，他們必須直接放到葉子塊上。
pctthreshold，行中的資料量超過塊的這個百分比時，行中餘下的列就儲存在溢位段中
including，行中第一列直到including子句所指定的列（包含這一列）的所有列都儲存到索引塊上，餘下的列儲存在溢位段中。
當行中某欄位的資料量無法確定時使用PCTTHRESHOLD。
若所有行均超出PCTTHRESHOLD規定大小，則考慮使用INCLUDING。


 IOT 就是類似一個全是索引的表，表中的所有欄位都放在索引上，所以就等於是約定了資料存放的時候是按照嚴格規定的，在資料插入以前其實就已經確定了其位置，所以不管插入的先後順序，它在那個物理上的那個位置與插入的先後順序無關。這樣在進行查詢的時候就可以少訪問很多blocks，但是插入的時候，速度就比普通的表要慢一些。
適用於資訊檢索、空間和OLAP程式。

使用IOT的好處：
1、由於索引項和資料儲存在一起，所以無論是基於主鍵的等值查詢還是範圍查詢都能大大節省磁碟訪問時間。
2、為了能夠更快地訪問那些頻繁訪問的列，可以使用溢位儲存選項將那些訪問不頻繁的列放在B樹葉結點資料塊之外的溢位堆空間中。這樣一來便可以得到更小的B樹，以及包含更多行的葉結點
3、和堆組織表和索引不同，主鍵不需要被儲存兩次。
4、ROWID偽列是基於主鍵值的邏輯rowid，而不是物理rowid，即使表被重新組織過，造成了基錶行的遷移，二級索引仍然可用，不需要重建。