文章詳情頁
有時Oracle不用索引來查找數(shù)據(jù)的原因
瀏覽:150日期:2023-11-15 08:58:01
當你運用 SQL 語言,向數(shù)據(jù)庫發(fā)布一條查詢語句時, Oracle 將伴隨產生一個“執(zhí)行計劃”,也就是該語句將通過何種數(shù)據(jù)搜索方案執(zhí)行,是通過全表掃描、還是通過索引搜尋等其它方式。搜索方案的選用與 ORACLE 的優(yōu)化器息息相關。 SQL 語句的執(zhí)行步驟。 1 語法分析 分析語句的語法是否符合規(guī)范,衡量語句中各表達式的意義。 2 語義分析 檢查語句中涉及的所有數(shù)據(jù)庫對象是否存在,且用戶有相應的權限。 3 視圖轉換 將涉及視圖的查詢語句轉換為相應的對基表查詢語句。 4 表達式轉換 將復雜的 SQL 表達式轉換為較簡單的等效連接表達式。 5 選擇優(yōu)化器 不同的優(yōu)化器一般產生不同的“執(zhí)行計劃” 6 選擇連接方式 ORACLE 有三種連接方式,對多表連接 ORACLE 可選擇適當?shù)倪B接方式。 7 選擇連接順序 對多表連接 ORACLE 選擇哪一對表先連接,選擇這兩表中哪個表做為源數(shù)據(jù)表。 8 選擇數(shù)據(jù)的搜索路徑 根據(jù)以上條件選擇合適的數(shù)據(jù)搜索路徑,如是選用全表搜索還是利用索引或是其他的方式。 9 運行“執(zhí)行計劃”。 ORACLE 的優(yōu)化器 ORACLE 有兩種優(yōu)化器:基于規(guī)則的優(yōu)化器( RBO , Rule Based Optimizer ),和基于代價的優(yōu)化器( CBO , Cost Based Optimizer )。 RBO 自 ORACLE 6 版以來被采用,有著一套嚴格的使用規(guī)則,只要你按照它去寫 SQL 語句,無論數(shù)據(jù)表中的內容怎樣,也不會影響到你的“執(zhí)行計劃”,也就是說對數(shù)據(jù)不“敏感”, ORACLE 公司已經(jīng)不再發(fā)展這種技術了。 CBO 自 ORACLE 7 版被引入, ORACLE 自 7 版以來采用的許多新技術都是基于 CBO 的,如星型連接排列查詢,哈希連接查詢,和并行查詢等。 CBO 計算各種可能“執(zhí)行計劃”的“代價”,即 cost ,從中選用 cost 最低的方案,作為實際運行方案。各“執(zhí)行計劃”的 cost 的計算根據(jù),依靠于數(shù)據(jù)表中數(shù)據(jù)的統(tǒng)計分布, ORACLE 數(shù)據(jù)庫本身對該統(tǒng)計分布并不清楚,須要分析表和相關的索引,才能搜集到 CBO 所需的數(shù)據(jù)。 一般而言, CBO 所選擇的“執(zhí)行計劃”都不會比 RBO 的“執(zhí)行計劃”差,而且相對而言, CBO 對程序員的要求沒有 RBO 那么苛刻,節(jié)省了程序員為了從多個可能的“執(zhí)行計劃”中選擇一個最優(yōu)的方案而花費的調試時間,但在某些場合下也會存在問題。 較典型的問題有:有時,表明明建有索引,但查詢過程顯然沒有用到相關的索引,導致查詢過程耗時漫長,占用資源巨大,問題到底出在哪兒呢?按照以下順序查找,基本上能發(fā)現(xiàn)原因所在。 查找原因的步驟 首先,我們要確定數(shù)據(jù)庫運行在何種優(yōu)化模式下,相應的參數(shù)是: optimizer_mode 。可在 svrmgrl 中運行“ show parameter optimizer_mode' 來查看。 ORACLE V7 以來缺省的設置應是 'choose' ,即假如對已分析的表查詢的話選擇 CBO ,否則選擇 RBO 。假如該參數(shù)設為“ rule ”,則不論表是否分析過,一概選用 RBO ,除非在語句中用 hint 強制。 其次,檢查被索引的列或組合索引的首列是否出現(xiàn)在 PL/SQL 語句的 WHERE 子句中,這是“執(zhí)行計劃”能用到相關索引的必要條件。 第三,看采用了哪種類型的連接方式。 ORACLE 的共有 Sort Merge Join ( SMJ )、 Hash Join ( HJ )和 Nested Loop Join ( NL )。在兩張表連接,且內表的目標列上建有索引時,只有 Nested Loop 才能有效地利用到該索引。 SMJ 即使相關列上建有索引,最多只能因索引的存在,避免數(shù)據(jù)排序過程。 HJ 由于須做 HASH 運算,索引的存在對數(shù)據(jù)查詢速度幾乎沒有影響。 第四,看連接順序是否答應使用相關索引。假設表 emp 的 deptno 列上有索引,表 dept 的列 deptno 上無索引, WHERE 語句有 emp.deptno=dept.deptno 條件。在做 NL 連接時, emp 做為外表,先被訪問,由于連接機制原因,外表的數(shù)據(jù)訪問方式是全表掃描, emp.deptno 上的索引顯然是用不上,最多在其上做索引全掃描或索引快速全掃描。 第五,是否用到系統(tǒng)數(shù)據(jù)字典表或視圖。由于系統(tǒng)數(shù)據(jù)字典表都未被分析過,可能導致極差的“執(zhí)行計劃”。但是不要擅自對數(shù)據(jù)字典表做分析,否則可能導致死鎖,或系統(tǒng)性能下降。 第六,是否存在潛在的數(shù)據(jù)類型轉換。如將字符型數(shù)據(jù)與數(shù)值型數(shù)據(jù)比較, ORACLE 會自動將字符型用 to_number() 函數(shù)進行轉換,從而導致第六種現(xiàn)象的發(fā)生。 第七,是否為表和相關的索引搜集足夠的統(tǒng)計數(shù)據(jù)。對數(shù)據(jù)經(jīng)常有增、刪、改的表最好定期對表和索引進行分析,可用 SQL 語句“ analyze table xxxx compute statistics for all indexes;' 。 ORACLE 把握了充分反映實際的統(tǒng)計數(shù)據(jù),才有可能做出正確的選擇。第八,索引列的選擇性不高。 我們假設典型情況,有表 emp ,共有一百萬行數(shù)據(jù),但其中的 emp.deptno 列,數(shù)據(jù)只有 4 種不同的值,如 10 、 20 、 30 、 40 。雖然 emp 數(shù)據(jù)行有很多, ORACLE 缺省認定表中列的值是在所有數(shù)據(jù)行均勻分布的,也就是說每種 deptno 值各有 25 萬數(shù)據(jù)行與之對應。假設 SQL 搜索條件 DEPTNO=10 ,利用 deptno 列上的索引進行數(shù)據(jù)搜索效率,往往不比全表掃描的高, ORACLE 理所當然對索引“視而不見”,認為該索引的選擇性不高。 但我們考慮另一種情況,假如一百萬數(shù)據(jù)行實際不是在 4 種 deptno 值間平均分配,其中有 99 萬行對應著值 10 , 5000 行對應值 20 , 3000 行對應值 30 , 2000 行對應值 40 。在這種數(shù)據(jù)分布圖案中對除值為 10 外的其它 deptno 值搜索時,毫無疑問,假如索引能被應用,那么效率會高出很多。我們可以采用對該索引列進行單獨分析,或用 analyze 語句對該列建立直方圖,對該列搜集足夠的統(tǒng)計數(shù)據(jù),使 ORACLE 在搜索選擇性較高的值能用上索引。 第九,索引列值是否可為空( NULL )。假如索引列值可以是空值,在 SQL 語句中那些需要返回 NULL 值的操作,將不會用到索引,如 COUNT ( * ),而是用全表掃描。這是因為索引中存儲值不能為全空。 第十一,看是否有用到并行查詢( PQO )。并行查詢將不會用到索引。如我們想要用到 A 表的 IND_COL1 索引的話,可采用以下方式: “ SELECT /*+ INDEX ( A IND_COL1 ) */ * FROM A WHERE COL1 = XXX;'注重,注釋符必須跟在 SELECT 之后,且注釋中的“ + ”要緊跟著注釋起始符“ /* ”或“ -- ”,否則 hint 就被認為是一般注釋,對 PL/SQL 語句的執(zhí)行不產生任何影響。 一種是 EXPLAIN TABLE 方式。用戶必須首先在自己的模式( SCHEMA )下,建立 PLAN_TABLE 表,執(zhí)行計劃的每一步驟都將記錄在該表中,建表 SQL 腳本為在 ${ORACLE_HOME}/rdbms/admin/ 下的 utlxplan.sql 。 打開 SQL*PLUS ,輸入“ SET AUTOTRACE ON ”,然后運行待調試的 SQL 語句。在給出查詢結果后, ORACLE 將顯示相應的“執(zhí)行計劃”,包括優(yōu)化器類型、執(zhí)行代價、連接方式、連接順序、數(shù)據(jù)搜索路徑以及相應的連續(xù)讀、物理讀等資源代價。 假如我們不能確定需要跟蹤的具體 SQL 語句,比如某個應用使用一段時間后,響應速度忽然變慢。我們這時可以利用 ORACLE 提供的另一個有力工具 TKPROF ,對應用的執(zhí)行過程全程跟蹤。我們要先在系統(tǒng)視圖 V$SESSION 中,可根據(jù) USERID 或 MACHINE ,查出相應的 SID 和 SERIAL# 。以 SYS 或其他有執(zhí)行 DBMS_SYSTEM 程序包的用戶連接數(shù)據(jù)庫,執(zhí)行“ EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION ( SID , SERIAL# , TRUE );”。 然后運行應用程序,這時在服務器端,數(shù)據(jù)庫參數(shù)“ USER_DUMP_DEST ”指示的目錄下,會生成 ora__xxxx.trc 文件,其中 xxxx 為被跟蹤應用的操作系統(tǒng)進程號。 應用程序執(zhí)行完成后,用命令 tkprof 對該文件進行分析。命令示例:“ tkprof tracefile outputfile explain=userid/passWord' 。在操作系統(tǒng) ORACLE 用戶下,鍵入“ tkprof ”,會有具體的命令幫助。分析后的輸出文件 outputfile 中,有每一條 PL/SQL 語句的“執(zhí)行計劃”、 CPU 占用、物理讀次數(shù)、邏輯讀次數(shù)、執(zhí)行時長等重要信息。根據(jù)輸出文件的信息,我們可以很快發(fā)現(xiàn)應用中哪條 PL/SQL 語句是問題的癥結所在。
標簽:
Oracle
數(shù)據(jù)庫
排行榜
