一次Oracle優化所想到的

我的原創連線：

一次Oracle優化所想到的 (qq.com)

有一次遇到一個問題。當然這圖已經被我塗抹的沒法看了（還是塗抹掉沒有風險）。但是依然能得出一些資訊。 （補充，該SQL根據報上來的情況是執行一次8秒以上）

1、10個表進行關聯（一個個數下來）

2、where就一個id（看數量級是一個，應該屬於點查）

3、省略了大量的列（列越多回表越大）

4、cost很大。(點查不應該這麼多)

5、用到了dblink（有remote）

要優化，這個工作其實涉及的東西非常多。索引、統計資訊、直方圖、巢狀關係、SQL寫法等等等，不瞭解資料庫的可能不以為然。可能最終我們能很快解決，但是涉及的東西不得不一一確認，可能性太多了。當然處理這個算我運氣好，只做了一個就好了。

就是上圖這個的紅框是左邊的這個列缺索引。造成了該表的全表。那麼先手工增加看看。效果顯而易見。cost從86000多將到680左右，理論提升120多倍。 實際反饋也是在80毫秒左右。速度提升也差不多是100多倍。理論和實際大體一致。

    事情表面結束了，那麼帶來的思考有如下：

1、我一向反對dblink關聯（所有要用物化檢視或者ogg來解決跨庫查詢）但是上面是實在沒辦法的背景下，只能硬著頭皮優化。這個背景是一個CDB之間的PDB跨庫查詢。實際看下來也還行。畢竟跨越N個PDB擺在那裡，好在沒有外部網路。PDB之間的dblink也不差。

2、不得不說Oracle強，一個PDB上的連線N個PDB，他的執行計劃還很準。

3、我一向反對多表關聯，不管在什麼資料庫上。這次是10表關聯，我其實看到也有點發怵，不懂業務邏輯下，太難評價每個環節，對還是不對，好還是不好。但是Oracle這優化器，還是準確的搞定了。為什麼說這個難？比如我們寫select from a,b where a.id=b.id and a.id=1;資料庫不知道ab是什麼。通常會改寫成select from a,b where a.id=b.id and a.id=1 and b=1;因為是等價的。至於先找a.id=1 還是 b=1看哪個優了。但是他有兩個選擇。如果三個表呢？他有6個組合選擇。即3！3的階乘。10個表呢就是10！，10的階乘是多大，我算不過來。這在任何資料庫中都是這樣。

   那麼是不是所有資料庫都能這樣跨資料庫，10表關聯出這個效果？估計不是。

4、最終在不改SQL的場景下，提升了100倍多，全靠資料庫自己的優化器和執行器完成。

5、有一次在一個PostgreSQL群中看到一位專業人士說到：說一個oracle極難被超越的地方，就是故障處理owi的思想。雖然國產很多也在借鑑，但是沒有做的很好的。即使現在，一個好的dba就是it後臺運維故障處理的入口，前臺只會說交易慢了，清算慢了，Oracle dba可以甚至可以最終定位到儲存光纖線光衰（硬體一點不報錯情況）。

    業內有的大咖說Oracle領先其他有代差，10-20年。從有些各種點滴場景來看，客觀上來說，這些評價都不過分。