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

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

熱門標(biāo)簽:地圖標(biāo)注原件 南通防封外呼系統(tǒng)運(yùn)營商 廣州市400電話辦理 淮安自動外呼系統(tǒng)開發(fā) 語音電話機(jī)器人缺點(diǎn) 宜賓外呼系統(tǒng)廠家 修改高德地圖標(biāo)注 語音電話機(jī)器人營銷方案 百變地圖標(biāo)注
正在看的ORACLE教程是:優(yōu)化Oracle庫表設(shè)計的若干方法。

 前言

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

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

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

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

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

  一個簡單的例子

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


  ORDER_ID是訂單號,為T_ORDER的主鍵,通過名為SEQ_ORDER_ID的序列產(chǎn)生鍵值,而ITEM_ID是T_ORDER_ITEM表的主鍵,通過名為SEQ_ORDER_ITEM的序列產(chǎn)生鍵值,T_ORDER_ITEM通過ORDER_ID外鍵關(guān)聯(lián)到T_ORDER表。

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

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

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

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

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


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

  ·沒有將表數(shù)據(jù)和索引數(shù)據(jù)存儲到不同的表空間中,而不加區(qū)別地將它們存儲到同一表空間里。這樣,不但會造成I/O競爭,也為數(shù)據(jù)庫的維護(hù)工作帶來不便。

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

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

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

[NextPage]

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

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

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

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

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

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

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

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

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

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

  將索引數(shù)據(jù)存儲在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)建兩個表空間。通過Model->Tablespace...在List of Tablespaces中創(chuàng)建兩個表空間:


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


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


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

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

  其次,需要考慮庫表數(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ù)模塊分開存放,這主要是考慮到備份問題。假設(shè)我們有一部分業(yè)務(wù)數(shù)據(jù)重要性很強(qiáng),而其他的業(yè)務(wù)數(shù)據(jù)重要性相對較弱,這樣就可以將兩者分開存儲,以便設(shè)置不同的備份策略。 

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

[NextPage]

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

  2

[1] [2] [3] 下一頁

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

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

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


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


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

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

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

  2.2 反向鍵索引的SQL語句

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

  ORDER_ID為T_ORDER表的主鍵,主鍵名為PK_ORDER,我們?yōu)镺RDER_ID列上建立一個反向鍵索引IDX_ORDER_ID,并使PK_ORDER_ID使用這個索引,其SQL語句如下:


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

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

  2.3 PowerdDesigner如何操作

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


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


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


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

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


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

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


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

[NextPage]

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

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

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


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


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


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

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

  3.2 壓縮型索引的SQL語句

  創(chuàng)建壓縮型索引的SQL語句非常簡單,在T_ORDER_ITEM的ORDER_ID上創(chuàng)建壓縮型索引的SQL如下所示:


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

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

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

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


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

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

  ·CLIENT + ORDER_DATE + IS_SHIPPED

  ·ORDER_DATE + IS_SHIPPED

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


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

  可以用許多工具來了解查詢語句的執(zhí)行計劃,通過SET AUTOTRACE ON來查詢以上兩個復(fù)合查詢的執(zhí)行計劃:

  打開SQL/Plus,輸入以下的語句:


  分析得到的執(zhí)行計劃為:


  可見Oracle先利用IDX_ORDER_COMPOSITE得到滿足條件的記錄ROWID,再通過ROWID返回記錄。

  而下面查詢語句:


  的執(zhí)行計劃則為:


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

  對復(fù)合列索引,我們得出這個結(jié)論:

 

上一頁  [1] [2] [3] 下一頁

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


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

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

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

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

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


  而組合條件為ORDER_DATE + IS_SHIPPED時的執(zhí)行計劃為:


  通過這樣的改造,我們得到了一個滿足兩種組合查詢的執(zhí)行計劃。

  總結(jié)

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

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

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

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

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

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

  ·??吹揭恍┝钗翌康脑O(shè)計:在需要進(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)。 

上一頁      

上一頁  [1] [2] [3] 

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

標(biāo)簽:通化 襄陽 嘉峪關(guān) 聊城 南平 股票投資 池州 南平

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《優(yōu)化Oracle庫表設(shè)計的若干方法》,本文關(guān)鍵詞  優(yōu)化,Oracle,庫表,設(shè)計,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《優(yōu)化Oracle庫表設(shè)計的若干方法》相關(guān)的同類信息!
  • 本頁收集關(guān)于優(yōu)化Oracle庫表設(shè)計的若干方法的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章