前言
絕大多數的Oracle數據庫性能問題都是由于數據庫設計不合理造成的，只有少部分問題根植于Database Buffer、Share Pool、Redo Log Buffer等內存模塊配置不合理，I/O爭用，CPU爭用等DBA職責范圍上。所以除非是面對一個業已完成不可變更的系統，否則我們不應過多地將關注點投向內存、I/O、CPU等性能調整項目上，而應關注數據庫表本身的設計是否合理，庫表設計的合理性才是程序性能的真正執牛耳者。
合理的數據庫設計需要考慮以下的方面：
·業務數據以何種方式表達。如一個員工有多個Email，你可以在T_EMPLOYEE表中建立多個Email字段如email_1、email_2、email_3，也可以創建一個T_EMAIL子表來存儲，甚至可以用逗號分隔開多個Email地址存放在一個字段中。
·數據以何種方式物理存儲。如大表的分區，表空間的合理設計等。
·如何建立合理的數據表索引。表索引幾乎是提高數據表查詢性能最有效的方法，Oracle擁有類型豐富的數據表索引類型，如何取舍選擇顯得特別重要。
本文我們將目光主要聚焦于數據表的索引上，同時也將提及其他兩點的內容。通過對一個簡單的庫表設計實例的分析引出設計中的不足，并逐一改正。考慮到手工編寫庫表的SQL腳本原始且低效，我們將用目前最流行的庫表設計工具PowerDesigner 10來講述表設計的過程，所以在本文中你還會了解到一些相關的PowerDesigner的使用技巧。
一個簡單的例子
某個開發人員著手設計一個訂單的系統，這個系統中有兩個主要的業務表，分別是訂單基本信息表和訂單條目表，這兩張表具有主從關系的表，其中T_ORDER是訂單主表，而T_ORDER_ITEM是訂單條目表。數據庫設計人員的設計成果如圖 1所示：
 圖 1 訂單主從表 |
ORDER_ID是訂單號，為T_ORDER的主鍵，通過名為SEQ_ORDER_ID的序列產生鍵值，而ITEM_ID是T_ORDER_ITEM表的主鍵，通過名為SEQ_ORDER_ITEM的序列產生鍵值，T_ORDER_ITEM通過ORDER_ID外鍵關聯到T_ORDER表。
需求文檔指出訂單記錄將通過以下兩種方式來查詢數據：
·CLIENT + ORDER_DATE+IS_SHPPED：根據"客戶＋訂貨日期+是否發貨"條件查詢訂單及訂單條目。
·ORDER_DATE+IS_SHIPPED：根據"訂貨日期+是否發貨"條件查詢訂單及訂單條目。
數據庫設計人員根據這個要求，在T_ORDER表的CLIENT、 ORDER_DATE及IS_SHPPED三字段上建立了一個復合索引IDX_ORDER_COMPOSITE；在T_ORDER_ITEM為外鍵ORDER_ID建立IDX_ORDER_ITEM_ORDER_ID索引。
讓我們看一下該份設計的最終SQL腳本：
create table T_ORDER ( ORDER_ID NUMBER(10) not null, ADDRESS VARCHAR2(100), CLIENT VARCHAR2(60), ORDER_DATE CHAR(8), IS_SHIPPED CHAR(1), constraint PK_T_ORDER primary key (ORDER_ID) ); create index IDX_CLIENT on T_ORDER ( CLIENT ASC, ORDER_DATE ASC, IS_SHIPPED ASC); create table T_ORDER_ITEM ( ITEM_ID NUMBER(10) not null, ORDER_ID NUMBER(10), ITEM VARCHAR2(20), COUNT NUMBER(10), constraint PK_T_ORDER_ITEM primary key (ITEM_ID) ); create index IDX_ORDER_ITEM_ORDER_ID on T_ORDER_ITEM ( ORDER_ID ASC); alter table T_ORDER_ITEM add constraint FK_T_ORDER__REFERENCE_T_ORDER foreign key (ORDER_ID) references T_ORDER (ORDER_ID); |
我們承認在ER關系上，這份設計并不存在的缺陷，但卻存在以下有待優化的地方：
·沒有將表數據和索引數據存儲到不同的表空間中，而不加區別地將它們存儲到同一表空間里。這樣，不但會造成I/O競爭，
