優化Oracle庫表設計的若干方法一

前言

絕大多數的oracle資料庫效能問題都是由於資料庫設計不合理造成的，只有少部分問題根植於database buffer、share

pool

、redo

logbuffer等記憶體模組配置不合理，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競爭，也為資料庫的維護工作帶來不便。

·oracle會自動為表的主鍵列建立乙個普通b-

tree

索引，但由於這兩張表的主鍵值都通過序列提供，具有嚴格的順序性（公升序或降序），此時手工為其指定乙個反鍵索引（reverse key index）將更加合理。

·在子表t_order_item外來鍵列order_id上建立的idx_order_item_order_id的普通b-tree索引非常適合設定為壓縮型索引，即建立乙個壓縮型的b-tree索引。因為乙份訂單會對應多個訂單條目，這就意味著t_order_item表存在許多同值的order_id列值，通過將其索引指定為壓縮型的b-tree索引，不但可以減少idx_order_item_order_id所需的儲存空間，還將提高表操作的效能。

·企圖僅通過建立乙個包含3欄位idx_order_composite復合索引滿足如前所述的兩種查詢條件方式的索引是有問題的，事實上使用order_date+is_shipped復合條件的查詢將利用不到idx_order_composite索引。

優化Oracle庫表設計的若干方法 一

優化Oracle庫表設計的若干方法

優化Oracle庫表設計的若干方法 三

優化Oracle庫表設計的若干方法 一

相關推薦

優化Oracle庫表設計的若干方法一

優化Oracle庫表設計的若干方法三

優化Oracle庫表設計的若干方法一