第二：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