sql優(yōu)化經(jīng)驗總結(jié)ppt課件(編輯修改稿)
2025-06-01 18:25 本頁面
【文章內(nèi)容簡介】 consistent gets ? 0 physical reads ? 0 redo size ? 547 bytes sent via SQL*Net to client ? 655 bytes received via SQL*Net from client ? 2 SQL*Net roundtrips to/from client ? 0 sorts (memory) ? 0 sorts (disk) ? 4 rows processed 18 第四章：如何分析問題的原因 ? 查找原因的一般步驟 19 查找原因的步驟（一） ? 檢查被索引的列或組合索引的首列是否出現(xiàn)在 PL/SQL語句的 WHERE子句 ? 看采用了哪種類型的連接方式。 ORACLE的共有 Sort Merge Join（歸并 SMJ）、 Hash Join（散列 HJ）和Nested Loop Join（嵌套循環(huán) NL）。在兩張表連接，且內(nèi)表的目標列上建有索引時，只有 Nested Loop才能有效地利用到該索引。 SMJ即使相關列上建有索引，最多只能因索引的存在，避免數(shù)據(jù)排序過程。 HJ由于須做 HASH運算，索引的存在對數(shù)據(jù)查詢速度幾乎沒有影響 20 查找原因的步驟（二） ? 看連接順序是否允許使用相關索引。假設表emp的 deptno列上有索引，表 dept的列 deptno上無索引， WHERE語句有=。在做 NL連接時，emp做為外表，先被訪問，由于連接機制原因，外表的數(shù)據(jù)訪問方式是全表掃描， 上的索引顯然是用不上，最多在其上做索引全掃描或索引快速全掃描 21 查找原因的步驟（三） ? 是否用到系統(tǒng)數(shù)據(jù)字典表或視圖。由于系統(tǒng)數(shù)據(jù)字典表都未被分析過，可能導致極差的“執(zhí)行計劃”。但是不要擅自對數(shù)據(jù)字典表做分析，否則可能導致死鎖，或系統(tǒng)性能下降 ? 索引列是否函數(shù)的參數(shù)。如是，索引在查詢時用不上 ? 是否存在潛在的數(shù)據(jù)類型轉(zhuǎn)換。如將字符型數(shù)據(jù)與數(shù)值型數(shù)據(jù)比較， ORACLE會自動將字符型用 to_number()函數(shù)進行轉(zhuǎn)換，從而導致第六種現(xiàn)象的發(fā)生 22 查找原因的步驟（四） ? 是否為表和相關的索引搜集足夠的統(tǒng)計數(shù)據(jù)。對數(shù)據(jù)經(jīng)常有增、刪、改的表最好定期對表和索引進行分析，可用 SQL語句“ analyze table xxxx pute statistics for all indexes?！?。ORACLE掌握了充分反映實際的統(tǒng)計數(shù)據(jù)，才有可能做出正確的選擇 ? 索引列的選擇性不高 （字段值重復率高） 23 查找原因的步驟（五） ? 索引列值是否可為空（ NULL）。如果索引列值可以是空值，在 SQL語句中那些需要返回 NULL值的操作，將不會用到索引，如 COUNT（ *），而是用全表掃描。這是因為索引中存儲值不能為全空 ? 看是否有用到并行查詢（ PQO）。并行查詢將不會用到索引 ? 看 PL/SQL語句中是否有用到 bind變量。由于數(shù)據(jù)庫不知道 bind變量具體是什么值，在做非相等連接時，如“ ”，“ ”,“l(fā)ike”等。 ORACLE將引用缺省值，在某些情況下會對執(zhí)行計劃造成影響 24 第五章： SQL重編譯問題 ? SQL共享原理 ? SQL共享的三個條件 ? PROC程序的 SQL共享 ? PROC程序中以下類型的語句不需進行變量綁定 ? PROC程序的 CLIENT參數(shù) ? 存儲過程的 SQL共享 ? SQL共享的數(shù)據(jù)庫參數(shù)的利弊 25 SQL共享原理 ? ORACLE將執(zhí)行過的 SQL語句存放在內(nèi)存的共享池 (shared buffer pool)中，可以被所有的數(shù)據(jù)庫用戶共享 ? 當你執(zhí)行一個 SQL語句 (有時被稱為一個游標 )時 ,如果它和之前的執(zhí)行過的語句完全相同 , ORACLE就能很快獲得已經(jīng)被解析的語句以及最好的 執(zhí)行路徑 . 這個功能大大地提高了 SQL的執(zhí)行性能
教學課件相關推薦
鄂ICP備17016276號-1