索引組織表(index organized table, IOT)就是存儲在一個索引結(jié)構(gòu)中的表。存儲在堆中的表是無組織的(也就是說，只要有可用的空間，數(shù)據(jù)可以放在任何地方)，IOT中的數(shù)據(jù)則按主鍵存儲和排序。對你的應(yīng)用來說，IOT表和一個“常規(guī)”表并無二致。
索引組織表的數(shù)據(jù)按主鍵排序手段被存儲在B-樹索引中，除了存儲主鍵列值外還存儲非鍵列的值。普通索引只存儲索引列，而索引組織表則存儲表的所有列的值。
索引組織表一般適應(yīng)于靜態(tài)表，且查詢多以主鍵列。當(dāng)表的大部分列當(dāng)作主鍵列時，且表相對靜態(tài)，比較適合創(chuàng)建索引組織表！（8i以上）
既然它屬于表，那么它當(dāng)然也有建立索引的需求。由于它的索引的結(jié)構(gòu)，比如說由于索引葉節(jié)點(diǎn)的分裂，行所在塊可能會發(fā)生改變，因而建立在IOT上的索引和一般的索引的最大區(qū)別是它存的是IOT的行的邏輯地址，也就是UROWID，oracle用這個邏輯rowid來猜這個行所在的塊，如果猜到了，那么這個urowid是正確的，否則它從這個地址向下遍歷來找這條記錄。
IOT表的rowid是邏輯上的，因為IOT表中的行的位置是在不斷變化的(例如插入新的行，有可能帶來其它行的位置移動)
IOT有什么意義呢？使用堆組織表時，我們必須為表和表主鍵上的索引分別留出空間。而IOT不存在主鍵的空間開銷，因為索引就是數(shù)據(jù)，數(shù)據(jù)就是索引，二者已經(jīng)合二為一。但是，IOT帶來的好處并不止于節(jié)約了磁盤空間的占用，更重要的是大幅度降低了I/O,減少了訪問緩沖區(qū)緩存(盡管從緩沖區(qū)緩存獲取數(shù)據(jù)比從硬盤讀要快得多，但緩沖區(qū)緩存并不免費(fèi)，而且也絕對不是廉價的。每個緩沖區(qū)緩存獲取都需要緩沖區(qū)緩存的多個閂，而閂是串行化設(shè)備，會限制應(yīng)用的擴(kuò)展能力)
IOT適用的場合有：
1、完全由主鍵組成的表。這樣的表如果采用堆組織表，則表本身完全是多余的開銷，因為所有的數(shù)據(jù)全部同樣也保存在索引里，此時，堆表是沒用的。
2、代碼查找表。如果你只會通過一個主鍵來訪問一個表，這個表就非常適合實現(xiàn)為IOT.
3、如果你想保證數(shù)據(jù)存儲在某個位置上，或者希望數(shù)據(jù)以某種特定的順序物理存儲，IOT就是一種合適的結(jié)構(gòu)。
IOT提供如下的好處：
·提高緩沖區(qū)緩存效率，因為給定查詢在緩存中需要的塊更少。
·減少緩沖區(qū)緩存訪問，這會改善可擴(kuò)縮性。
·獲取數(shù)據(jù)的工作總量更少，因為獲取數(shù)據(jù)更快。
·每個查詢完成的物理I/O更少，因為對于任何給定的查詢，需要的塊更少，而且對地址記錄的一個物理 I/O 很可能可以獲取所有地址（而不只是其中一個地址，但堆表實現(xiàn)就只是獲取一個地址）
如果經(jīng)常在一個主鍵或惟一鍵上使用BETWEEN 查詢也是如此，因為相近的記錄存在一起，查詢時引入的邏輯IO和物理IO都會更少。
索引組織表的詳細(xì)參數(shù)
ops$tkyte@ORA10GR1> select dbms_metadata.get_ddl( 'TABLE', 'T1' ) from dual;
S_METADATA.GET_DDL('TABLE','T1')
-----------------------------------------------------------------------------
CREATE TABLE "OPS$TKYTE"."T1"
"X" NUMBER(*,0),
"Y" VARCHAR2(25),
"Z" DATE,
PRIMARY KEY ("X") ENABLE
ANIZATION INDEX
OMPRESS
PCTFREE 10 INITRANS 2 MAXTRANS 255 LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS"
PCTTHRESHOLD 50
NOCOMPRESS 選項
這個選項對索引一般都可用。它告訴 Oracle 把每個值分別存儲在各個索引條目中（也就是不壓縮）。如果對象的主鍵在 A、B 和 C 列上， A、B 和 C 的每一次出現(xiàn)都會物理地存儲。 NOCOMPRESS 反過來就是 COMPRESS N ，在此 N 是一個整數(shù)，表示要壓縮的列數(shù)。這樣可以避免重復(fù)值，并在塊級提取 “公因子”（ factor out ）。這樣在 A 的值（以及 B 的值）重復(fù)出現(xiàn)時，將不再物理地存儲它們。
下面做一個快速的測試，對前面 CREATE TABLE 的 SELECT 分別采用 NOCOMPRESS 、 COMPRESS 1 和COMPRESS 2 選項，來展示能節(jié)省多少空間。先來創(chuàng)建 IOT ，但不進(jìn)行壓縮：
ops$tkyte@ORA10GR1> create table iot
2 ( owner, object_type, object_name,
3 constraint iot_pk primary key(owner,object_type,object_name)
4 )
5 organization index
6 NOCOMPRESS
7 as
8 select distinct owner, object_type, object_name
9 from all_objects
10 /
tablle created.
現(xiàn)在可以測量所用的空間。為此我們將使用 ANALYZE INDEX VALIDATE STRUCTURE 命令。這個命令會填寫一個名為 INDEX_STATS 的動態(tài)性能視圖，其中最多只包含一行，即這個 ANALYZE 命令最后一次執(zhí)行的信息：
ops$tkyte@ORA10GR1> analyze index iot_pk validate structure;
index analyzed.
ops$tkyte@ORA10GR1> select lf_blks, br_blks, used_space,
2 opt_cmpr_count, opt_cmpr_pctsave
3 from index_stats;
LF_BLKS BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
284 3 2037248 2 33
由此顯示出，我們的索引目前使用了 284 個葉子塊（即數(shù)據(jù)所在的塊），并使用了 3 個分支塊（ Oracle在索引結(jié)構(gòu)中導(dǎo)航所用的塊）來找到這些葉子塊。使用的空間大約是 2MB （2,038,248 字節(jié)）。另外兩列名字有些奇怪，這兩列是要告訴我們一些信息。 OPT_CMPR_COUNT （最優(yōu)壓縮數(shù)）列要說的是：“ 如果你把這個索引置為 COMPRESS 2 ，就會得到最佳的壓縮 ” 。 OPT_CMPR_PCTSAVE （最優(yōu)的節(jié)省壓縮百分比）則是說 ，如果執(zhí)行 COMPRESS 2 ，就能節(jié)省大約 1/3 的存儲空間，索引只會使用現(xiàn)在 2 /3 的磁盤空間。
下面用COMPRESS 2進(jìn)行壓縮：
ops$tkyte@ORA10GR1> alter table iot move compress 2;
Table altered.
ops$tkyte@ORA10GR1> analyze index iot_pk validate structure;
Index analyzed.
ops$tkyte@ORA10GR1> select lf_blks, br_blks, used_space,
2 opt_cmpr_count, opt_cmpr_pctsave
3 from index_stats;
LF_BLKS BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
190 1 1359357 2 0
現(xiàn)在大小有了顯著減少，不論是葉子塊數(shù)還是總的使用空間都大幅下降。
（關(guān)于這個參數(shù)的詳細(xì)說明參見第十一章 索引 11.2.1借 索引鍵壓縮 ）
OVERFLOW&PCTTHRESHOLD&INCLUDING選項
OVERFLOW 子句允許你建立另一個段（這就使得 IOT 成為一個多段對象，就像有一個 CLOB 列一樣），如果 IOT 的行數(shù)據(jù)變得太大，就可以溢出到這個段中。
注意：構(gòu)成主鍵的列不能溢出，它們必須直接放在葉子塊上。
PCTTHRESHOLD ：行中的數(shù)據(jù)量超過塊的這個百分比時，行中余下的列將存儲在溢出段中。所以，如果 PCTTHRESHOLD 是 10% ，而塊大小是 8KB ，長度大于 800 字節(jié)的行就會把其中一部分存儲在別處，而不能在索引塊上存儲。
INCLUDING ：行中從第一列直到 INCLUDING 子句所指定列（也包括這一列）的所有列都存儲在索引塊上，余下的列存儲在溢出段中。
對于 IOT 最后要考慮的是建立索引。 IOT 本身可以有一個索引，就像在索引之上再加索引，這稱為二次索引（ secondary index ）。 正常情況下，索引包含了所指向的行的物理地址，即 rowid 。而 IOT 二次索引無法做到這一點(diǎn)；它必須使用另外某種方法來指示行的地址。這是因為 IOT 中 的行可以大量移動， 而且它不像堆組織表中的行那樣 “ 遷移 ” 。 IOT 中的行肯定在索引結(jié)構(gòu)中的每個位置上，這取決于它的主鍵值；只有當(dāng)索引本身的大小和形狀 發(fā)生改變時行才會移動（下一章將更詳細(xì)地討論索引結(jié)構(gòu)如何維護(hù)）。
為了適應(yīng)這種情況， O racle 引入了一個邏輯 rowid （ logical rowid ）。 這些邏輯 rowid 根據(jù) IOT 主鍵建立。對于行的當(dāng)前位置還可以包含一個 “ 猜測 ” ，不過這個猜測幾乎是錯的，因為稍過一段時間后， IOT中的數(shù)據(jù)可能就會 移動。這個猜測是行第一次置于二次索引結(jié)構(gòu)中時在 IOT 中的物理地址。如果 IOT 中 的行必須移動到另外一個塊上，二次索引中的猜測就會變得 “ 過時 ” 。因 此，與常規(guī)表相比， IOT 上的索 引效率稍低。在一個常規(guī)表上，索引訪問通常需要完成一個 I/O 來掃描索引結(jié)構(gòu)，然后需要一個讀來讀取表數(shù)據(jù)。對于 IOT ， 通常要 完成兩個掃描；一次掃描二次結(jié)構(gòu)，另一次掃描 IOT 本身。除此之外， IOT 上的索引可以使用非主鍵列提供 IOT 數(shù)據(jù)的快速、高效訪問。
索引組織表小結(jié)
在 建立 IOT 時，最關(guān)鍵的是適當(dāng)?shù)胤峙鋽?shù)據(jù)，即哪些數(shù)據(jù)存儲在索引塊上，哪些數(shù)據(jù)存儲在溢出段上。對溢出條件不同的各種場景進(jìn)行基準(zhǔn)測試，查看對 INSERT 、 UPDATE 、 DELETE 和 SELECT 分別有怎樣的影響。如果結(jié)構(gòu)只建立一次，而且要頻繁讀取，就應(yīng)該盡可能地把數(shù)據(jù)放在索引塊上（最合適獲取），要么頻繁地組織索引中的數(shù)據(jù)（不適于修改）。堆表的 freelist 相關(guān)考慮對 IOT 也同樣適用。 PCTFREE 和PCTUSED 在 IOT 中 是兩個重要的角色。不過， PCTFREE 對于 IOT 不像對于堆表那么重要，另外 PC TUSED 一般不起作用。不過，考慮 OVERFLOW 段時， PCTFREE 和 PCTUSED 對于 IOT 的意義將與對于堆表一樣重大；要采用與堆表相同的邏輯為溢出段設(shè)置這兩個參數(shù)。