sql編寫規(guī)范和優(yōu)化講稿-資料下載頁
2025-03-10 20:13本頁面
【正文】 blue_collar, count (sale when sal 5000 then 1 else null end) count_poor from emp。 這樣查詢的結果一樣，但是執(zhí)行計劃只進行了一次全表查詢 SQL優(yōu)化 (oracle) ?使用 nls_date_format 例 9： select * from record where to_char(ActionTime,39。mm39。)=39。1239。 這個查詢的執(zhí)行計劃將是全表查詢，如果我們改變nls_date_format， SQLalert session set nls_date_formate=’MM’。 現(xiàn)在重新修改上面的查詢： select * from record where ActionTime=39。1239。 這樣就能使用 actiontime上的索引了，它的執(zhí)行計劃將是（ INDEX RANGE SCAN） SQL優(yōu)化 (oracle) ?使用基于函數(shù)的索引 前面談到任何對列的操作都可能導致全表掃描，例如： select * from emp where substr(ename,1,2)=’SM’。 但是這種查詢在客服系統(tǒng)又經常使用，我們可以創(chuàng)建一個帶有 substr函數(shù)的基于函數(shù)的索引， create index emp_ename_substr on eemp ( substr(ename,1,2) )。 這樣在執(zhí)行上面的查詢語句時，這個基于函數(shù)的索引將排上用場，執(zhí)行計劃將是（ INDEX RANGE SCAN）。 SQL優(yōu)化 (oracle) ? 基于函數(shù)的索引要求等式匹配 上面的例子中，我們創(chuàng)建了基于函數(shù)的索引，但是如果執(zhí)行下面的查詢： select * from emp where substr(ename,1,1)=’S’ 得到的執(zhí)行計劃將還是（ TABLE ACCESS FULL），因為只有當數(shù)據(jù)列能夠等式匹配時，基于函數(shù)的索引才能生效，這樣對于這種索引的計劃和維護的要求都很高。請注意，向表中添加索引是非常危險的操作，因為這將導致許多查詢執(zhí)行計劃的變更。然而，如果我們使用基于函數(shù)的索引就不會產生這樣的問題，因為 Oracle只有在查詢使用了匹配的內置函數(shù)時才會使用這種類型的索引。 SQL優(yōu)化 (oracle) ?使用分區(qū)索引 在用分析命令對分區(qū)索引進行分析時，每一個分區(qū)的數(shù)據(jù)值的范圍信息會放入 Oracle的數(shù)據(jù)字典中。Oracle可以利用這個信息來提取出那些只與 SQL查詢相關的數(shù)據(jù)分區(qū)。 例如，假設你已經定義了一個分區(qū)索引，并且某個SQL語句需要在一個索引分區(qū)中進行一次索引掃描。Oracle會僅僅訪問這個索引分區(qū)，而且會在這個分區(qū)上調用一個此索引范圍的快速全掃描。因為不需要訪問整個索引，所以提高了查詢的速度。 SQL優(yōu)化 (oracle) ?使用位圖索引 位圖索引可以從本質上提高使用了小于 1000個唯一數(shù)據(jù)值的數(shù)據(jù)列的查詢速度，因為在位圖索引中進行的檢索是在 RAM中完成的，而且也總是比傳統(tǒng)的 B樹索引的速度要快。對于那些少于 1000個唯一數(shù)據(jù)值的數(shù)據(jù)列建立位圖索引，可以使執(zhí)行效率更快。 SQL優(yōu)化 (oracle) ?決定使用全表掃描還是使用索引 和所有的秘笈一樣，最后一招都會又回到起點，最后我們來討論一下是否需要建立索引，也許進行全表掃描更快。在大多數(shù)情況下，全表掃描可能會導致更多的物理磁盤輸入輸出，但是全表掃描有時又可能會因為高度并行化的存在而執(zhí)行的更快。如果查詢的表完全沒有順序，那么一個要返回記錄數(shù)小于 10％的查詢可能會讀取表中大部分的數(shù)據(jù)塊，這樣使用索引會使查詢效率提高很多。但是如果表非常有順序，那么如果查詢的記錄數(shù)大于 40％時，可能使用全表掃描更快。 SQL優(yōu)化 (oracle) ?決定使用全表掃描還是使用索引 因此，有一個索引范圍掃描的總體原則是： 1）對于原始排序的表 僅讀取少于表記錄數(shù) 40％的查詢應該使用索引范圍掃描。反之，讀取記錄數(shù)目多于表記錄數(shù)的 40％的查詢應該使用全表掃描。 2）對于未排序的表 僅讀取少于表記錄數(shù) 7％的查詢應該使用索引范圍掃描。反之，讀取記錄數(shù)目多于表記錄數(shù)的 7％的查詢應該使用全表掃描。 SQL優(yōu)化 (oracle) ? 以上的十八招式，是完全可以相互結合同時運用的。而且各種方法之間相互影響，緊密聯(lián)系。這種聯(lián)系既存在一致性，也可能帶來沖突，當沖突發(fā)生時，需要根據(jù)實際情況進行選擇，沒有固定的模式。最后決定 SQL優(yōu)化功力的因素就是對ORACLE內功的掌握程度了。 ? 另外，值得注意的是：隨著時間的推移和數(shù)據(jù)的累計與變化，ORACLE對 SQL語句的執(zhí)行計劃也會改變，比如：基于代價的優(yōu)化方法，隨著數(shù)據(jù)量的增大，優(yōu)化器可能錯誤的不選擇索引而采用全表掃描。這種情況可能是因為統(tǒng)計信息已經過時，在數(shù)據(jù)量變化很大后沒有及時分析表；但如果對表進行分析之后，仍然沒有用上合理的索引，那么就有必要對 SQL語句用 HINT提示，強制用合理的索引。 SQL優(yōu)化 (oracle) ? 但這種 HINT提示也不能濫用，因為這種方法過于復雜，缺乏通用性和應變能力，同時也增加了維護上的代價；相對來說，基于函數(shù)右移、去掉“ IN ， OR ， ， IS NOT NULL ” 、分解復雜的 SQL語句等等方法，卻是“放之四海皆準”的，可以放心大膽的使用。 ? 同時，優(yōu)化也不是“一勞永逸”的，必須隨著情況的改變進行相應的調整。當數(shù)據(jù)庫設計發(fā)生變化，包括更改表結構：字段和索引的增加、刪除或改名等；業(yè)務邏輯發(fā)生變化：如查詢方式、取值范圍發(fā)生改變等等。在這種情況下，也必須對原有的優(yōu)化進行調整，以適應效率上的需求。 演講完畢，謝謝觀看！
公司管理相關推薦
鄂ICP備17016276號-1