2、顯式為主鍵列建立反向鍵索引
2.1 反向鍵索引的原理和用途
我們知道oracle會自動為表的主鍵列建立索引，這個預設的索引是普通的b-tree索引。對於主鍵值是按順序(遞增或遞減)加入的情況，預設的b-tree索引並不理想。這是因為如果索引列的值具有嚴格順序時，隨著資料行的插入，索引樹的層級增長很快。搜尋索引發生的i/o讀寫次數和索引樹的層級數成正比，也就是說，一棵具有5個層級的b-tree索引，在最終讀取到索引資料時最多可能發生多達5次i/o操作。因而，減少索引的層級數是索引效能調整的乙個重要方法。
如果索引列的資料以嚴格的有序的方式插入，那麼b-tree索引樹將變成一棵不對稱的"歪樹"，如圖 5所示：
圖 5不對稱的b-tree索引
而如果索引列的資料以隨機值的方式插入，我們將得到一棵趨向對稱的索引樹，如圖 6所示：
圖 6對稱的b-tree索引
比較圖 5和圖 6，在圖 5中搜尋到a塊需要進行5次i/o操作，而圖 6僅需要3次i/o操作。
既然索引列資料從序列中獲取，其有序性無法規避，但在建立索引時，oracle允許對索引列的值進行反向，即預先對列值進行位元位的反向，如1000,10001,10011,10111,1100經過反向後的值將是0001,1001,1101,0011。顯然經過位反向處理的有序資料變得比較隨機了，這樣所得到的索引樹就比較對稱，從而提高表的查詢效能。
但反向鍵索引也有它侷限性：如果在where語句中，需要對索引列的值進行範圍性的搜尋，如between、<、>等，其反向鍵索引無法使用，此時，oracle將執行全表掃瞄；只有對反向鍵索引列進行 <> 和 = 的比較操作時，其反向鍵索引才會得到使用。
2.2 反向鍵索引的sql語句
回到我們上面的例子，由於t_order和t_order_item的主鍵值**於序列，主鍵值是有嚴格順序的，所以我們應該摒棄預設的oracle所提供的索引，而採取顯式為主鍵指定乙個反向鍵索引的方式。
order_id為t_order表的主鍵，主鍵名為pk_order，我們為order_id列上建立乙個反向鍵索引idx_order_id，並使pk_order_id使用這個索引，其sql語句如下：
create table t_order (
order_id number(10) not null,
client varchar2(60),
address varchar2(100),
order_date char(8));
create unique index idx_order_id on t_order ( order_id asc)reverse;alter table t_order add constraint pk_order primary key (order_id) using index idx_order_id;
要保證建立idx_order_id的sql語句在建立pk_order主鍵的sql語句之前，因為主鍵需要引用到這個反向鍵索引。
由於主鍵列的資料是唯一的，所以為idx_order_id加上unique限定，使其成為唯一型的索引。
create table t_order (…);alter table t_order add constraint pk_t_order primary key (order_id) using index idx_order_id;createuniqueindex idx_order_id on t_order ( order_id asc)reverse;
優化Oracle庫表設計的若干方法
1.oracle會自動為表的主鍵列建立索引，這個預設的索引是普通的b tree索引 2.索引本身實際上是乙個表，因此當對表新增乙個記錄時，oracle必須做兩次插入。這樣，組表增加乙個索引將導致插入操作要兩倍多的時間 兩倍的時間用於兩次插入，另外還需要一點時間處理二表之間 的同步 增加兩個索引將使用...
優化Oracle庫表設計的若干方法 一
前言 絕大多數的oracle資料庫效能問題都是由於資料庫設計不合理造成的，只有少部分問題根植於database buffer share pool redo logbuffer等記憶體模組配置不合理，i o爭用，cpu爭用等 dba職責範圍上。所以除非是面對乙個業已完成不可變更的系統，否則我們不應過...
優化Oracle庫表設計的若干方法 一
前言 絕大多數的oracle資料庫效能問題都是由於資料庫設計不合理造成的，只有少部分問題根植於database buffer share pool redo log buffer等記憶體模組配置不合理，i o爭用，cpu爭用等dba職責範圍上。所以除非是面對乙個業已完成不可變更的系統，否則我們不應過...