主頁(yè) > 知識(shí)庫(kù) > 優(yōu)化Oracle庫(kù)表設(shè)計(jì)的若干方法

優(yōu)化Oracle庫(kù)表設(shè)計(jì)的若干方法

正在看的ORACLE教程是:優(yōu)化Oracle庫(kù)表設(shè)計(jì)的若干方法。

　前言

　　絕大多數(shù)的Oracle數(shù)據(jù)庫(kù)性能問(wèn)題都是由于數(shù)據(jù)庫(kù)設(shè)計(jì)不合理造成的，只有少部分問(wèn)題根植于Database Buffer、Share Pool、Redo Log Buffer等內(nèi)存模塊配置不合理，I/O爭(zhēng)用，CPU爭(zhēng)用等DBA職責(zé)范圍上。所以除非是面對(duì)一個(gè)業(yè)已完成不可變更的系統(tǒng)，否則我們不應(yīng)過(guò)多地將關(guān)注點(diǎn)投向內(nèi)存、I/O、CPU等性能調(diào)整項(xiàng)目上，而應(yīng)關(guān)注數(shù)據(jù)庫(kù)表本身的設(shè)計(jì)是否合理，庫(kù)表設(shè)計(jì)的合理性才是程序性能的真正執(zhí)牛耳者。
合理的數(shù)據(jù)庫(kù)設(shè)計(jì)需要考慮以下的方面：

　　·業(yè)務(wù)數(shù)據(jù)以何種方式表達(dá)。如一個(gè)員工有多個(gè)Email，你可以在T_EMPLOYEE表中建立多個(gè)Email字段如email_1、email_2、email_3，也可以創(chuàng)建一個(gè)T_EMAIL子表來(lái)存儲(chǔ)，甚至可以用逗號(hào)分隔開(kāi)多個(gè)Email地址存放在一個(gè)字段中。

　　·數(shù)據(jù)以何種方式物理存儲(chǔ)。如大表的分區(qū)，表空間的合理設(shè)計(jì)等。

　　·如何建立合理的數(shù)據(jù)表索引。表索引幾乎是提高數(shù)據(jù)表查詢性能最有效的方法，Oracle擁有類(lèi)型豐富的數(shù)據(jù)表索引類(lèi)型，如何取舍選擇顯得特別重要。

　　本文我們將目光主要聚焦于數(shù)據(jù)表的索引上，同時(shí)也將提及其他兩點(diǎn)的內(nèi)容。通過(guò)對(duì)一個(gè)簡(jiǎn)單的庫(kù)表設(shè)計(jì)實(shí)例的分析引出設(shè)計(jì)中的不足，并逐一改正?？紤]到手工編寫(xiě)庫(kù)表的SQL腳本原始且低效，我們將用目前最流行的庫(kù)表設(shè)計(jì)工具PowerDesigner 10來(lái)講述表設(shè)計(jì)的過(guò)程，所以在本文中你還會(huì)了解到一些相關(guān)的PowerDesigner的使用技巧。

　　一個(gè)簡(jiǎn)單的例子

　　某個(gè)開(kāi)發(fā)人員著手設(shè)計(jì)一個(gè)訂單的系統(tǒng)，這個(gè)系統(tǒng)中有兩個(gè)主要的業(yè)務(wù)表，分別是訂單基本信息表和訂單條目表，這兩張表具有主從關(guān)系的表，其中T_ORDER是訂單主表，而T_ORDER_ITEM是訂單條目表。數(shù)據(jù)庫(kù)設(shè)計(jì)人員的設(shè)計(jì)成果如圖 1所示：

　　ORDER_ID是訂單號(hào)，為T(mén)_ORDER的主鍵，通過(guò)名為SEQ_ORDER_ID的序列產(chǎn)生鍵值，而ITEM_ID是T_ORDER_ITEM表的主鍵，通過(guò)名為SEQ_ORDER_ITEM的序列產(chǎn)生鍵值，T_ORDER_ITEM通過(guò)ORDER_ID外鍵關(guān)聯(lián)到T_ORDER表。

　　需求文檔指出訂單記錄將通過(guò)以下兩種方式來(lái)查詢數(shù)據(jù)：

　　·CLIENT + ORDER_DATE+IS_SHPPED：根據(jù)"客戶＋訂貨日期+是否發(fā)貨"條件查詢訂單及訂單條目。

　　·ORDER_DATE+IS_SHIPPED：根據(jù)"訂貨日期+是否發(fā)貨"條件查詢訂單及訂單條目。

　　數(shù)據(jù)庫(kù)設(shè)計(jì)人員根據(jù)這個(gè)要求，在T_ORDER表的CLIENT、 ORDER_DATE及IS_SHPPED三字段上建立了一個(gè)復(fù)合索引IDX_ORDER_COMPOSITE；在T_ORDER_ITEM為外鍵ORDER_ID建立IDX_ORDER_ITEM_ORDER_ID索引。

　　讓我們看一下該份設(shè)計(jì)的最終SQL腳本：

　　我們承認(rèn)在ER關(guān)系上，這份設(shè)計(jì)并不存在的缺陷，但卻存在以下有待優(yōu)化的地方：

　　·沒(méi)有將表數(shù)據(jù)和索引數(shù)據(jù)存儲(chǔ)到不同的表空間中，而不加區(qū)別地將它們存儲(chǔ)到同一表空間里。這樣，不但會(huì)造成I/O競(jìng)爭(zhēng)，也為數(shù)據(jù)庫(kù)的維護(hù)工作帶來(lái)不便。

　　·ORACLE會(huì)自動(dòng)為表的主鍵列創(chuàng)建一個(gè)普通B-Tree索引，但由于這兩張表的主鍵值都通過(guò)序列提供，具有嚴(yán)格的順序性（升序或降序），此時(shí)手工為其指定一個(gè)反鍵索引（reverse key index）將更加合理。

　　·在子表T_ORDER_ITEM外鍵列ORDER_ID上建立的IDX_ORDER_ITEM_ORDER_ID的普通B-Tree索引非常適合設(shè)置為壓縮型索引，即建立一個(gè)壓縮型的B-Tree索引。因?yàn)橐环萦唵螘?huì)對(duì)應(yīng)多個(gè)訂單條目，這就意味著T_ORDER_ITEM表存在許多同值的ORDER_ID列值，通過(guò)將其索引指定為壓縮型的B-Tree索引，不但可以減少I(mǎi)DX_ORDER_ITEM_ORDER_ID所需的存儲(chǔ)空間，還將提高表操作的性能。

　　·企圖僅通過(guò)建立一個(gè)包含3字段IDX_ORDER_COMPOSITE復(fù)合索引滿足如前所述的兩種查詢條件方式的索引是有問(wèn)題的，事實(shí)上使用ORDER_DATE+IS_SHIPPED復(fù)合條件的查詢將利用不到IDX_ORDER_COMPOSITE索引。

[NextPage]

　優(yōu)化設(shè)計(jì)

　　1、將表數(shù)據(jù)和索引數(shù)據(jù)分開(kāi)表空間存儲(chǔ)

　　1.1 表數(shù)據(jù)和索引為何需要使用獨(dú)立的表空間

　　Oracle強(qiáng)烈建立，任何一個(gè)應(yīng)用程序的庫(kù)表至少需要?jiǎng)?chuàng)建兩個(gè)表空間，其中之一用于存儲(chǔ)表數(shù)據(jù)，而另一個(gè)用于存儲(chǔ)表索引數(shù)據(jù)。因?yàn)槿绻麑⒈頂?shù)據(jù)和索引數(shù)據(jù)放在一起，表數(shù)據(jù)的I/O操作和索引的I/O操作將產(chǎn)生影響系統(tǒng)性能的I/O競(jìng)爭(zhēng)，降低系統(tǒng)的響應(yīng)效率。將表數(shù)據(jù)和索引數(shù)據(jù)存放在不同的表空間中（如一個(gè)為APP_DATA，另一個(gè)為APP_IDX），并在物理層面將這兩個(gè)表空間的數(shù)據(jù)文件放在不同的物理磁盤(pán)上，就可以避免這種競(jìng)爭(zhēng)了。

　　擁有獨(dú)立的表空間，就意味著可以獨(dú)立地為表數(shù)據(jù)和索引數(shù)據(jù)提供獨(dú)立的物理存儲(chǔ)參數(shù)，而不會(huì)發(fā)生相互影響，畢竟表數(shù)據(jù)和索引數(shù)據(jù)擁有不同的特性，而這些特性又直接影響了物理存儲(chǔ)參數(shù)的設(shè)定。

　　此外，表數(shù)據(jù)和索引數(shù)據(jù)獨(dú)立存儲(chǔ)，還會(huì)帶來(lái)數(shù)據(jù)管理和維護(hù)上的方面。如你在遷移一個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)時(shí)，為了降低數(shù)據(jù)大小，可以只遷出表數(shù)據(jù)的表空間，在目標(biāo)數(shù)據(jù)庫(kù)中通過(guò)重建索引的方式就可以生成索引數(shù)據(jù)了。

　　1.2 表數(shù)據(jù)和索引使用不同表空間的SQL語(yǔ)法

　　指定表數(shù)據(jù)及索引數(shù)據(jù)存儲(chǔ)表空間語(yǔ)句最簡(jiǎn)單的形式如下。

　　將表數(shù)據(jù)存儲(chǔ)在APP_DATA表空間里：

create table T_ORDER ( ORDER_ID NUMBER(10) not null, …)tablespace APP_DATA;

　　將索引數(shù)據(jù)存儲(chǔ)在APP_IDX表空間里：

create index IDX_ORDER_ITEM_ORDER_ID on T_ORDER_ITEM ( ORDER_ID ASC)tablespace APP_IDX;

　　1.3 PowerDesigner中如何操作

　　1) 首先，必須創(chuàng)建兩個(gè)表空間。通過(guò)Model->Tablespace...在List of Tablespaces中創(chuàng)建兩個(gè)表空間：

　　2) 為每張表指定表數(shù)據(jù)存儲(chǔ)的表空間。在設(shè)計(jì)區(qū)中雙擊表，打開(kāi)Table Properties設(shè)計(jì)窗口，切換到options 頁(yè)，按圖 3所示指定表數(shù)據(jù)的存儲(chǔ)表空間。

　　3) 為每個(gè)索引指定索引數(shù)據(jù)的存儲(chǔ)表空間。在Table Properties中切換到Indexes頁(yè)，在這里列出了表的所有索引，雙擊需設(shè)置表空間的索引，在彈出的Index Properties窗口中切換到Options頁(yè)，按如下方式指定索引的存儲(chǔ)表空間。

　　將表空間的問(wèn)題延展一下：一個(gè)應(yīng)用系統(tǒng)庫(kù)表的表空間可以進(jìn)行更精細(xì)的劃分。

　　首先，如果表中存在LOB類(lèi)型的字段，有為其指定一個(gè)特定的表空間，因?yàn)長(zhǎng)OB類(lèi)型的數(shù)據(jù)在物理存儲(chǔ)結(jié)構(gòu)的管理上和一般數(shù)據(jù)的策略有很大的不同，將其放在一個(gè)獨(dú)立的表空間中，就可方便地設(shè)置其物理存儲(chǔ)參數(shù)了。

　　其次，需要考慮庫(kù)表數(shù)據(jù)的DML操作特性：根據(jù)DML（INSERT,UPDATE,DELETE）操作頻繁程度，將幾乎不發(fā)生任何DML操作的數(shù)據(jù)放在獨(dú)立的表空間中，因?yàn)闃O少DML操作的表可設(shè)置符合其特性的物理參數(shù)：如PCTFREE可置為0，其BUFFER_POOL指定為KEEP，以便將數(shù)據(jù)緩存在KEEP數(shù)據(jù)緩存區(qū)中等等，不一而足。

　　此外，還可以考慮按業(yè)務(wù)需要將不同的業(yè)務(wù)模塊分開(kāi)存放，這主要是考慮到備份問(wèn)題。假設(shè)我們有一部分業(yè)務(wù)數(shù)據(jù)重要性很強(qiáng)，而其他的業(yè)務(wù)數(shù)據(jù)重要性相對(duì)較弱，這樣就可以將兩者分開(kāi)存儲(chǔ)，以便設(shè)置不同的備份策略。

　　當(dāng)然，無(wú)節(jié)制的細(xì)化表空間也將帶來(lái)管理上和部署上的復(fù)雜，根據(jù)業(yè)務(wù)需求合理地規(guī)劃表空間以達(dá)到管理和性能上的最佳往往需要更多的權(quán)衡。

[NextPage]

2、顯式為主鍵列建立反向鍵索引

　　2

[1] [2] [3] 下一頁(yè)

正在看的ORACLE教程是:優(yōu)化Oracle庫(kù)表設(shè)計(jì)的若干方法。.1 反向鍵索引的原理和用途

　　我們知道Oracle會(huì)自動(dòng)為表的主鍵列建立索引，這個(gè)默認(rèn)的索引是普通的B-Tree索引。對(duì)于主鍵值是按順序(遞增或遞減)加入的情況，默認(rèn)的B-Tree索引并不理想。這是因?yàn)槿绻饕械闹稻哂袊?yán)格順序時(shí)，隨著數(shù)據(jù)行的插入，索引樹(shù)的層級(jí)增長(zhǎng)很快。搜索索引發(fā)生的I/O讀寫(xiě)次數(shù)和索引樹(shù)的層級(jí)數(shù)成正比，也就是說(shuō)，一棵具有5個(gè)層級(jí)的B-Tree索引，在最終讀取到索引數(shù)據(jù)時(shí)最多可能發(fā)生多達(dá)5次I/O操作。因而，減少索引的層級(jí)數(shù)是索引性能調(diào)整的一個(gè)重要方法。

　　如果索引列的數(shù)據(jù)以嚴(yán)格的有序的方式插入，那么B-Tree索引樹(shù)將變成一棵不對(duì)稱(chēng)的"歪樹(shù)"，如圖 5所示：

　　而如果索引列的數(shù)據(jù)以隨機(jī)值的方式插入，我們將得到一棵趨向?qū)ΨQ(chēng)的索引樹(shù)，如圖 6所示：

　　比較圖 5和圖 6，在圖 5中搜索到A塊需要進(jìn)行5次I/O操作，而圖 6僅需要3次I/O操作。

　　既然索引列數(shù)據(jù)從序列中獲取，其有序性無(wú)法規(guī)避，但在建立索引時(shí)，Oracle允許對(duì)索引列的值進(jìn)行反向，即預(yù)先對(duì)列值進(jìn)行比特位的反向，如1000,10001,10011,10111,1100經(jīng)過(guò)反向后的值將是0001,1001,1101,0011。顯然經(jīng)過(guò)位反向處理的有序數(shù)據(jù)變得比較隨機(jī)了，這樣所得到的索引樹(shù)就比較對(duì)稱(chēng)，從而提高表的查詢性能。

　　但反向鍵索引也有它局限性：如果在WHERE語(yǔ)句中，需要對(duì)索引列的值進(jìn)行范圍性的搜索，如BETWEEN、、>等，其反向鍵索引無(wú)法使用，此時(shí)，Oracle將執(zhí)行全表掃描；只有對(duì)反向鍵索引列進(jìn)行 > 和 = 的比較操作時(shí)，其反向鍵索引才會(huì)得到使用。

　　2.2 反向鍵索引的SQL語(yǔ)句

　　回到我們上面的例子，由于T_ORDER和T_ORDER_ITEM的主鍵值來(lái)源于序列，主鍵值是有嚴(yán)格順序的，所以我們應(yīng)該摒棄默認(rèn)的Oracle所提供的索引，而采取顯式為主鍵指定一個(gè)反向鍵索引的方式。

　　ORDER_ID為T(mén)_ORDER表的主鍵，主鍵名為PK_ORDER，我們?yōu)镺RDER_ID列上建立一個(gè)反向鍵索引IDX_ORDER_ID，并使PK_ORDER_ID使用這個(gè)索引，其SQL語(yǔ)句如下：

　　要保證創(chuàng)建IDX_ORDER_ID的SQL語(yǔ)句在創(chuàng)建PK_ORDER主鍵的SQL語(yǔ)句之前，因?yàn)橹麈I需要引用到這個(gè)反向鍵索引。

　　由于主鍵列的數(shù)據(jù)是唯一的，所以為IDX_ORDER_ID加上unique限定，使其成為唯一型的索引。

　　2.3 PowerdDesigner如何操作

　　1) 首先，需要為ORDER_ID列建立一個(gè)反向鍵索引。打開(kāi)T_ORDER的Table Properties的窗口，切換到Indexes頁(yè)，新建一個(gè)名為IDX_ORDER_ID的索引。填寫(xiě)完索引的名稱(chēng)后，雙擊這個(gè)索引，彈出Index Properties窗口，在這個(gè)窗口的Columns中選擇ORDER_ID列。然后，切換到Options頁(yè)，按圖 7的方式將其設(shè)置為反向鍵索引。

　　2) 顯式指定主鍵PK_ORDER使用這個(gè)索引。在Table Properties窗口中切換到Keys頁(yè)，默認(rèn)情況下，PowerDesigner為T(mén)_ORDER所指定的主鍵名為Key1，我們將其更名為PK_ORDER，雙擊這個(gè)主鍵，彈出Key Properties窗口，切換到Options頁(yè)，按圖 8的方式為PK_ORDER指定IDX_ORDER_ID。

　　不可否認(rèn)PowerDesigner確實(shí)是目前業(yè)界最強(qiáng)大易用的數(shù)據(jù)庫(kù)設(shè)計(jì)工具，但很遺憾，當(dāng)我們?yōu)楸碇麈I指定一個(gè)索引時(shí)，其產(chǎn)生的語(yǔ)句在順序上有問(wèn)題：即創(chuàng)建主鍵的語(yǔ)句位于創(chuàng)建索引語(yǔ)句之前：

　　我們可以通過(guò)對(duì)PowerDesigner生成SQL語(yǔ)句的設(shè)置進(jìn)行調(diào)整，先生成創(chuàng)建表和索引的SQL語(yǔ)句，再創(chuàng)建為表添加主鍵和外鍵的SQL語(yǔ)句來(lái)達(dá)到曲線救國(guó)的目的，請(qǐng)看下一步。

　　3)通過(guò)菜單Database->Generate Database...調(diào)出Database Configuration窗口，切換到KeysIndexes頁(yè)，按圖 9設(shè)置：

　　這里，我們將Primary Keys和Foreign keys的選項(xiàng)都取消，而將Indexes勾選，以達(dá)到只生成表的索引SQL語(yǔ)句的目的。

　　點(diǎn)擊"確定"后，生成創(chuàng)建數(shù)據(jù)庫(kù)表及其索引的SQL語(yǔ)句，運(yùn)行該SQL創(chuàng)建數(shù)據(jù)庫(kù)后，再按圖 10設(shè)置生成為表添加主鍵和外鍵的SQL語(yǔ)句：

　　除此設(shè)置外，還必須切換到Tables Views頁(yè)下，取消所有選項(xiàng)，避免重新生成創(chuàng)建表的語(yǔ)句。

[NextPage]

3、將子表的外鍵列的索引改為壓縮型

　　3.1 壓縮型索引的原理和用途

　　在前面的例子中，由于一條訂單會(huì)對(duì)應(yīng)多條訂單條目，所以T_ORDER_ITEM的ORDER_ID字段總會(huì)出現(xiàn)重復(fù)的值，如：

　　在ORDER_ID列上創(chuàng)建一個(gè)普通未壓縮的B-Tree索引，則索引數(shù)據(jù)的物理上的存儲(chǔ)形式如下：

　　ORDER_ID的重復(fù)值在索引塊中重復(fù)出現(xiàn)，這樣不但增加了存儲(chǔ)空間的需求，而且因?yàn)椴樵儠r(shí)需要讀取更多的索引數(shù)據(jù)塊，所以查詢性能也會(huì)降低＝。讓我們來(lái)看一下經(jīng)過(guò)壓縮后索引數(shù)據(jù)的存儲(chǔ)方式：

　　壓縮型的索引消除了重復(fù)的索引值，將相同索引列值所關(guān)聯(lián)的ROWID存儲(chǔ)在一起。這樣，不但節(jié)省了存儲(chǔ)空間，查詢效率也提高了，真可謂兩全齊美了。

　　對(duì)象T_ORDER和T_ORDER_ITEM這樣的主從表進(jìn)行查詢時(shí)，一般情況下，我們都必須通過(guò)外鍵查詢出子表所有關(guān)聯(lián)的記錄，所以在子表的外鍵上建立壓縮型的索引是非常適合的。

　　3.2 壓縮型索引的SQL語(yǔ)句

　　創(chuàng)建壓縮型索引的SQL語(yǔ)句非常簡(jiǎn)單，在T_ORDER_ITEM的ORDER_ID上創(chuàng)建壓縮型索引的SQL如下所示：

　　需要在創(chuàng)建索引的語(yǔ)句后附上compress關(guān)鍵字就可以了。

　　3.3 PowerDesigner如何創(chuàng)建壓縮型索引

　　1) 打開(kāi)T_ORDER_ITEM表的Table Properties的窗口，切換到Indexes頁(yè)，為ORDER_ID列創(chuàng)建一個(gè)名為IDX_ORDER_ITEM_ORDER_ID的索引。

　　2) 雙擊IDX_ORDER_ITEM_ORDER_ID彈出Index Properties窗口，切換到Options頁(yè)，按圖 13將索引設(shè)置為壓縮型：

　　4、建立滿足需求的復(fù)合鍵索引

　　設(shè)計(jì)人員希望通過(guò)T_ORDER表上的IDX_ORDER_COMPOSITE復(fù)合索引滿足以下兩種組合條件的查詢：

　　·CLIENT + ORDER_DATE + IS_SHIPPED

　　·ORDER_DATE + IS_SHIPPED

　　為方便闡述，我們特地將IDX_ORDER_COMPOSITE的創(chuàng)建SQL語(yǔ)句再次列出：

　　事實(shí)上，在CLIENT + ORDER_DATE + IS_SHIPPED 三列上所執(zhí)行的復(fù)合條件查詢會(huì)應(yīng)用到這個(gè)索引，而在ORDER_DATE + IS_SHIPPED列上所執(zhí)行的復(fù)合查詢不會(huì)使用這個(gè)索引，因而將導(dǎo)致一個(gè)全表掃描的操作。

　　可以用許多工具來(lái)了解查詢語(yǔ)句的執(zhí)行計(jì)劃，通過(guò)SET AUTOTRACE ON來(lái)查詢以上兩個(gè)復(fù)合查詢的執(zhí)行計(jì)劃：

　　打開(kāi)SQL/Plus，輸入以下的語(yǔ)句：

　　分析得到的執(zhí)行計(jì)劃為：

　　可見(jiàn)Oracle先利用IDX_ORDER_COMPOSITE得到滿足條件的記錄ROWID，再通過(guò)ROWID返回記錄。

　　而下面查詢語(yǔ)句：

　　的執(zhí)行計(jì)劃則為：

　　很明顯，Oracle在T_ORDER表上執(zhí)行了一個(gè)全表掃描的操作，沒(méi)有用到IDX_ORDER_COMPOSITE索引。

　　對(duì)復(fù)合列索引，我們得出這個(gè)結(jié)論：

　

上一頁(yè) [1] [2] [3] 下一頁(yè)

正在看的ORACLE教程是:優(yōu)化Oracle庫(kù)表設(shè)計(jì)的若干方法?！〖僭O(shè)在COL_1,COL_2,…,COL_n這些列上建立了一個(gè)復(fù)合索引：

　　則只有WHERE語(yǔ)句上包含COL_1(復(fù)合索引的第一個(gè)字段)的查詢才會(huì)使用這個(gè)復(fù)合索引，而未包含COL_1的查詢則不會(huì)使用這個(gè)復(fù)合索引。

　　回到我們的例子，如何建立滿足CLIENT + ORDER_DATE + IS_SHIPPED和ORDER_DATE + IS_SHIPPED兩種查詢的索引呢？

　　考慮到IS_SHIPPED列基數(shù)很小，只有兩個(gè)可能的值：0,1。在這種情況下，有兩種方案：第一，分別為CLIENT + ORDER_DATE + IS_SHIPPED和ORDER_DATE + IS_SHIPPED建立一個(gè)復(fù)合索引；第二，分別在CLIENT和ORDER_DATE列上建立一個(gè)索引，而IS_SHIPEED列不建立索引。

　　第一種方案的查詢效率最快，但因?yàn)镃LIENT和ORDER_DATE在索引中會(huì)重復(fù)出現(xiàn)兩次，占用較大的存儲(chǔ)空間。第二種方案CLIENT和ORDER_DATE不會(huì)在索引存儲(chǔ)出現(xiàn)兩次，較為節(jié)省空間，查詢效率比之于第一種方案會(huì)稍低一些，但影響不大。

　　我們采用第二種方案為CLIENT和ORDER_DATE分別創(chuàng)建索引IDX_CLIENT和IDX_ORDER_DATE，組合查詢條件為CLIENT + ORDER_DATE + IS_SHIPPED時(shí)的執(zhí)行計(jì)劃為：

　　而組合條件為ORDER_DATE + IS_SHIPPED時(shí)的執(zhí)行計(jì)劃為：

　　通過(guò)這樣的改造，我們得到了一個(gè)滿足兩種組合查詢的執(zhí)行計(jì)劃。

　　總結(jié)

　　貫穿本文的訂單主從表實(shí)例結(jié)構(gòu)上很簡(jiǎn)單，但是其粗糙的設(shè)計(jì)包含了許多問(wèn)題，這也是許多對(duì)Oracle物理存儲(chǔ)結(jié)構(gòu)沒(méi)有很好理解的數(shù)據(jù)庫(kù)設(shè)計(jì)師容易忽視的地方。

　　在一般情況下，這樣的設(shè)計(jì)并不會(huì)導(dǎo)致嚴(yán)重系統(tǒng)的性能問(wèn)題，但是精益求精是每一位優(yōu)秀軟件設(shè)計(jì)師的品質(zhì)，此外，對(duì)于設(shè)計(jì)師，一定要清楚這樣一條規(guī)律：對(duì)于等質(zhì)的性能提升，在編碼層面往往需要比設(shè)計(jì)層面付出更多的艱辛。

　　在Oracle中提高數(shù)據(jù)庫(kù)的性能需要考慮的問(wèn)題，注意的誤區(qū)還很多，本文涵蓋是一些最常見(jiàn)的問(wèn)題。下面，我們將提高數(shù)據(jù)庫(kù)操作性能方法及一些誤區(qū)作個(gè)小結(jié)：

　　·對(duì)于大表，可以考慮創(chuàng)建分區(qū)表，分區(qū)表有范圍分區(qū)、散列分區(qū)、列表分區(qū)和散列分區(qū)幾種，通過(guò)它可以達(dá)到化大表為小表的目的。

　　·考慮適量的數(shù)據(jù)冗余，如一個(gè)業(yè)務(wù)表有一個(gè)審批狀態(tài)，審批需要經(jīng)過(guò)多步，每一步對(duì)應(yīng)審批表的一條記錄，最后審批的那條記錄決定了業(yè)務(wù)的狀態(tài)。我們大可在業(yè)務(wù)表中存放一個(gè)審批狀態(tài)的標(biāo)志，以取消每次需要通過(guò)關(guān)聯(lián)審批表獲取業(yè)務(wù)審批狀態(tài)的復(fù)雜的關(guān)聯(lián)表查詢。

　　·不要做太多的關(guān)聯(lián)表查詢，一些幾乎不發(fā)生數(shù)據(jù)變動(dòng)的表碼表，如性別，學(xué)歷，婚姻狀態(tài)等表碼表，可以考慮在應(yīng)用程序啟動(dòng)時(shí)一次性地下載到應(yīng)用程序的內(nèi)存中緩存起來(lái)，在從數(shù)據(jù)庫(kù)獲取結(jié)果集后，再由程序利用這些緩存的表碼表數(shù)據(jù)來(lái)翻譯這些表碼字段，而不要在數(shù)據(jù)庫(kù)中通過(guò)表間的關(guān)聯(lián)查詢方式來(lái)翻譯這些字段。

　　·常看到一些令我瞠目的設(shè)計(jì)：在需要進(jìn)行頻繁DML(INSERT,UPDATE,DELETE)操作的表的某些基數(shù)低的字段（如性別，婚姻狀態(tài)）上創(chuàng)建位圖索引。位圖索引是好東西，但它是有使用范圍的，在OLTP系統(tǒng)中，需要進(jìn)行頻繁DML操作的表中不應(yīng)該出現(xiàn)位圖索引，位圖索引只適用于幾乎不進(jìn)行DML操作，只進(jìn)行查詢的DSS系統(tǒng)中。此外，聚簇和索引組織表也都更適合DSS系統(tǒng)，而非OLTP系統(tǒng)。

上一頁(yè)

上一頁(yè) [1] [2] [3]

您可能感興趣的文章:

Oracle CBO優(yōu)化模式中的5種索引訪問(wèn)方法淺析
oracle數(shù)據(jù)庫(kù)sql的優(yōu)化總結(jié)
Oracle SQL tuning 數(shù)據(jù)庫(kù)優(yōu)化步驟分享(圖文教程)
Oracle 查詢優(yōu)化的基本準(zhǔn)則詳解
Oracle存儲(chǔ)過(guò)程的編寫(xiě)經(jīng)驗(yàn)與優(yōu)化措施(分享)
oracle下一條SQL語(yǔ)句的優(yōu)化過(guò)程(比較詳細(xì))
oracle 性能優(yōu)化建議小結(jié)
oracle 優(yōu)化的一點(diǎn)體會(huì)
SQL優(yōu)化之針對(duì)count、表的連接順序、條件順序、in及exist的優(yōu)化

標(biāo)簽：衡水湘潭崇左仙桃蘭州湖南銅川黃山

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《優(yōu)化Oracle庫(kù)表設(shè)計(jì)的若干方法》，本文關(guān)鍵詞；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題，煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們，我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無(wú)關(guān)。