【文章內(nèi)容簡介】 ) 1 0 SORT (AGGREGATE) 2 1 INDEX (FAST FULL SCAN) OF 39。CKT_SPKFK39。 (INDEX (UNIQUE)) ( Cost=22 Card=31883 Bytes=382596)我們看到第一個求count(*) 變相選擇PK_SPKFK做為索引掃描，第二個HINT被忽略了，而做全表掃描，只有第三個求count(spbh),選擇索引掃描，為什么呢？因為，要對表的記錄求總數(shù)，HINT的索引是唯一索引且不為空，如果CBO選擇在索引上做了COUNT,當索引字段有空值時，count字段必然不準確，當做COUNT(*)的時候oracle會默認選擇不為空的的索引做掃描，這就是基于代價的優(yōu)化器（CBO）的好處了。而第二個求count(xslb)因為改字段可為空，oracle找不到合適的索引做掃描，而HINT使用的CKT_SPKFK是建在spbh字段的索引，做count的時候結(jié)果必然不準確。比如T表實際上有一千條數(shù)據(jù)，spbh字段有100空，xslb有200個空，這樣求count(xslb)使用索引掃描得出的是900個，顯然數(shù)據(jù)是錯誤的。所以這種情況下CBO是不會做索引的，因為他會導致錯誤的結(jié)果。而當在索引上創(chuàng)建了主鍵pk_spkfk，這樣就保證了該字段不為空。當再次地表做count(*)的時候指定的HINT就起作用了，因為索引不為空，對索引的COUNT和對表的COUNT值是相同的。還有在日常維護中，發(fā)現(xiàn)表關(guān)聯(lián)的操作比較多，經(jīng)過對系統(tǒng)的實驗得出了一個結(jié)論：大表間的關(guān)聯(lián)操作使用HASH JOIN會比 NESTED JOIN效率高一點，小表間的關(guān)聯(lián)通常選擇NESTED JOIN 比HASH JOIN效率高些，而一般能用MERGE JOIN提高性能的地方，HASH JOIN都會發(fā)現(xiàn)更出色的性能。 變量綁定變量綁定是OLTP數(shù)據(jù)庫系統(tǒng)中一個非常重要的技術(shù)點。良好的變量綁定會是OLTP系統(tǒng)數(shù)據(jù)庫中的SQL跑的飛快，內(nèi)存效率極高；不綁定變量可能會使OLTP數(shù)據(jù)庫不堪重負，資源被SQL解析嚴重消耗，系統(tǒng)顯得滯重而緩慢。我們知道一條sql在數(shù)據(jù)中是怎么被執(zhí)行的，一條SQL被發(fā)送到服務器中，會做一個HASH函數(shù)運算，得到一個HASH值，然后到共享池中找到是否有何這個HASH值匹配的SQL存在，如果找到了，oracle直接使用已經(jīng)存在的執(zhí)行計劃去執(zhí)行這條SQL，然后將結(jié)果返回給用戶，如果在共享池中沒有找到，則把他當做一條新的SQL,將會按照以下順序執(zhí)行，語法分析語義分析生成執(zhí)行計劃SQL的執(zhí)行。下面對比一個一條SQL執(zhí)行了10000次時，綁定變量和非綁定變量在資源上的消耗情況例一：PARSING IN CURSOR 1 len=119 dep=0 uid=55 oct=47 lid=55 tim=1017528684 hv=293694880 =39。c6937c7839。beginfor x in 1..10000 loopexecute immediate 39。select * from all_objects where object_name=:x39。 using x。end loop。end。END OF STMTPARSE 1:c=0,e=1536,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1017528682執(zhí)行時間：+=CPU時間：+=分析次數(shù)：34次執(zhí)行次數(shù)：10084次例二 PARSING IN CURSOR 1 len=113 dep=0 uid=0 oct=47 lid=0 tim=4150023581 hv=1876790916 ad=39。c66d826039。beginfor x in 1..10000 loopexecute immediate 39。select * from all_objects where object_name=39。||x。 end loop。end。END OF STMTPARSE 1:c=0,e=1701,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=4150023579執(zhí)行時間：+=CPU時間：+=分析次數(shù)：30002次執(zhí)行次數(shù)：30003次兩種情況對比的結(jié)果顯示，綁定變量SQL的資源消耗要遠遠少于未綁定變量的SQL資源消耗，sql的執(zhí)行次數(shù)越多，這種差距就越明顯，未綁定變量SQL的資源主要消耗在產(chǎn)生遞歸SQL中，這些SQL主要是對SQL語句做硬分析時使用的。如果我們讓所有用戶在數(shù)據(jù)庫操作中傳給ORACLE的都是這樣一個由變量代替常量的SQL,那么oracle只需要硬分析第一條sql就可以了，這樣省掉了前面很耗資源的硬分析過程。 使用索引 管理組織索引索引可以大大加快數(shù)據(jù)庫的查詢速度，索引把表中的邏輯值映射到安全的RowID，因此索引能進行快速定位數(shù)據(jù)的物理地址。但是有些DBA發(fā)現(xiàn)，對一個大型表建立的索引，并不能改善數(shù)據(jù)查詢速度，反而會影響整個數(shù)據(jù)庫的性能。這主要是和SGA的數(shù)據(jù)管理方式有關(guān)。ORACLE在進行數(shù)據(jù)塊高速緩存管理時，索引數(shù)據(jù)比普通數(shù)據(jù)具有更高的駐留權(quán)限，在進行空間競爭時，ORACLE會先移出普通數(shù)據(jù)。對一個建有索引的大型表的查詢時，索引數(shù)據(jù)可能會用完所有的數(shù)據(jù)塊緩存空間，ORACLE不得不頻繁地進行磁盤讀寫來獲取數(shù)據(jù)，因此在對一個大型表進行分區(qū)之后，可以根據(jù)相應的分區(qū)建立分區(qū)索引。如果對這樣大型表的數(shù)據(jù)查詢比較頻繁，或者干脆不建索引。另外，DBA創(chuàng)建索引時，應盡量保證該索引最可能地被用于where子句中，如果對查詢只簡單地制定一個索引，并不一定會加快速度，因為索引必須指定一個適合所需的訪問路徑[2] 聚簇的使用Oracle提供了另一種方法來提高查詢速度，就是聚簇（Cluster）。所謂聚簇，簡單地說就是把幾個表放在一起，按一定公共屬性混合存放。聚簇根據(jù)共同碼值將多個表的數(shù)據(jù)存儲在同一個Oracle塊中，這時檢索一組Oracle塊就同時得到兩個表的數(shù)據(jù)，這樣就可以減少需要存儲的Oracle塊，從而提高應用程序的性能。優(yōu)化設(shè)置的索引，就必須充分利用才能加快數(shù)據(jù)庫訪問速度。ORACLE要使用一個索引，有一些最基本的條件：a、where子名中的這個字段，必須是復合索引的第一個字段；b、where子名中的這個字段，不應該參與任何形式的計算。 使用分析函數(shù)分析函數(shù)可以減少表掃描的次數(shù)，下面先看一個ERP系統(tǒng)中分析函數(shù)使用提高數(shù)據(jù)庫性能的案例：select distinct peer_id, nvl(, 1) ne_state from dcc_sys_log dsl1, (select distinct peer_id, decode(action, 39。disconnect39。, 0, 39。connect39。, 0, 1) ne_state from dcc_sys_log dsl, dcc_ne_log dnl where = and (( = 39。disconnect39。 and = 39。關(guān)閉對端39。) or ( = 39。connect39。 and = 39。連接主機失敗39。)) and log_type = 39。對端交互39。 and = (select max(log_time) from dcc_sys_log where peer_id = and log_type = 39。對端交互39。)) ne_disconnect_info where = (+)原先至少需要掃描2次！現(xiàn)在根據(jù)KEEP結(jié)合DENSE_RANK的方式，將表掃描從2次變?yōu)榱?次，具體代碼改寫如下：SELECT ,CA