第二:SQL的優化永遠只針對大表之間的連接才用得上。不要懷疑,首先,我說的大表是指包含大表,不管是大表與大表,還是大表與小表
注:本文不是給你一個案例,而是講調優的方法,古人云:授人魚不如授人漁,這里要講的,就是教你怎么捕魚。
這里要說的sql調優很有意思,得先從感恩節說起。
感恩節(英語:Thanksgiving Day)是美國和加拿大共有的節日,由美國人民獨創,原意是為了感謝上天賜予的好收成。11月的第四個星期四是感恩節。感恩節是美國人民獨創的一個古老節日,也是美國人合家歡聚的節日,因此美國人提起感恩節總是備感親切。感恩節是美國國定假日中最地道、最美國式的節日。
感恩節之后的第一天,是星期五,在這一天,美國人有瘋狂購物的習慣,所以被稱之為黑色星期五,近來己經由傳統的商場購物改為網上購物,所以我的愕運便由此而生,我的DB便在這一天被瘋狂購物給訪問爆了。
客戶提供了一份高峰時段的AWR報告,仔細分析后,發現竟然是一條高耗CPU的SQL給整跨了,僅僅一條,占了85%的CPU,這才深入去了解了SQL的優化,以前也做過DB的一些優化,基本上通過分析表、建索引、調參數、打PATCH等等都能解決,但這次,持續了一周,學了幾天,還沒解決。最終決定潛心研究SQL的優化,得出以下幾點關于優化的結論:
第 一:1/9原則,引用Oracle大牛Tom大師的原話:數據庫中90%的性能問題都可以由調整10%的SQL語句來解決。
Tom say: Sql tuning constitute a good 90 percent or more of the effort. Thats right; before we even get the DBAs involved, we the developers have done 90 percent of the work. This is why I think most people do not understand database tuning.
第二:SQL的優化永遠只針對大表之間的連接才用得上。不要懷疑,,首先,我說的大表是指包含大表,不管是大表與大表,還是大表與小表,只要是有大表就行,因為小表與小表之間不會出現性能問題;其次:有連接才有優化的價值,我真的不知道單表的SQL有什么優化可言,對單表查詢無非是三點:全表/索引/分區表,這三點,你肯定會。
第 三:說第三條之間,先說明:正如前面兩條所言,數據庫90%的優化在SQL,SQL的優化關鍵在“大表連接”,所以下面說的SQL優化都是指大表連接。
SQL的執行中,Oracle提供的執行計劃,不是什么神秘的東西,其實就是oracle去表中查找我們所需結果的一個算法,算法這東西太熟了,在大學《數據結構》這門課中就學過(慚愧,這堂課從來都是去睡覺,因為當時根本不知道那位老朽在說什么),算法就是運算過程,在這里,就是指查找路徑,說白了:執行計劃=算法=查找路徑,要找最優的執行計劃,就是要找出最優算法,最優算法熟吧? 不熟我跟你說幾個名詞:"冒泡算法",“折中算法”,“快速查找”,去過軟件公司面試的人很多人肯定都做過這種題。而Oracle提供的執行計劃中,恰恰就提供這些詳細的過程在里面。你能看到Oracle先去哪個表/索引拿數據、根據什么條件拿多少行,再把拿到的結果去連接哪個表、等等,經過一系列的運算,最后得出什么結果給你。
但是,ORACLE也是一款軟件,不是神,你給它一條SQL,它在開始運算之前,是不知道哪種算法是最優的,不可能每個都試一遍,再做比較吧,而且每條語句的執行計劃上百種,每條語句都執行上百次,那服務器干脆別活了。所以,它只能預估一種針對這條SQL認為最優的算法,然后去執行。請注意:
1.永遠沒有最優算法,如果有最優算法a,那優化還需要做嗎?每次都按最優算法a做行了。
2. Oracle認為最優的算法也不一定是最優算法,如果是的話,我們還需要做嗎?
說到這里:我們就明白了,ORACLE調優的90%=SQL調優=大表連接調優=執行計劃調優=算法調優,而大表連接就2點:1.連接順序。2.連接算法(嵌套/哈希/合并)。
結論:SQL的調優就是手動設計出最優連接順序和算法的執行計劃。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com