Oracle調優專家秘籍

註：本文不是給你一個案例，而是講調優的方法，古人云：授人魚不如授人漁，這裡要講的，就是教你怎麼捕魚。

這裡要說的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. Thatʹs right; before we even get the DBAʹs 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的調優就是手動設計出最優串連順序和演算法的執行計畫。