今天不寫優化，說點感想和建議（昨天就要發的，結果第一次用手機操作，發錯了，只發出去一張網上找的美圖）：

在oracle做研發和售後這麼多年，為很多大客戶的資料庫做了優化，這些客戶的系統都是非常重要的系統，而且都配備了非常專業的DBA（或者聘請了業界知名的第三方維護團隊），但是查出來的效能問題還是觸目驚心（第一次優化前都是抱著試試看的態度，看了優化報告才知道問題有多嚴重，系統還有那麼多的優化空間），可想而知其他中小客戶的系統面臨的是一個什麼情況。

“系統慢不是問題，只要不崩潰就行”，可能這是大多數DBA的想法。

但是，如果你的系統經常出一些故障（硬體問題除外，不過如果磁碟經常壞，應該也和效能有關），很多時候就是因為：沒有使用繫結變數、錯誤的設定了一些優化器引數、併發過大、缺少索引（最普遍）、統計資訊不準確、SQL寫法不佳、RAC系統按照單節點設計等等一系列效能問題，導致系統壓力過大而出現的狀況。

但是好多人寧願出故障時救火，卻不願意花時間去優化資料庫。試想如果你的系統經過全面優化，負載很小，還會經常出各種問題嗎？

100%的資料庫都是可以優化的，CPU降低，資源爭用小，系統就會更加穩定；IO壓力降低，SQL執行速度加快，磁碟壽命也會更長。

現在的普遍問題是：

大部分DBA對資料庫的優化還只停留在引數調整上，而引數調整能帶來的優化效果一般是非常小的（除非遇到嚴重錯誤的引數設定），而且經常因為改了一些引數導致效能更差。AWR報告更是基本不看。還有一些水平高一些的DBA，認為自己管理的庫已經沒啥好優化的，實際上還是問題一大堆。
好的DBA應該能發現SQL效能問題，將問題反饋給研發，更高一個層次的還會將如何改進告訴研發人員。

而研發人員基本上為了實現功能就已經焦頭爛額了，如果SQL執行的不是非常慢，根本不會考慮其效能問題，只有在效率實在無法接受時，才會想盡各種辦法（分步、分割槽、分表、併發）讓業務得以在要求的時間內完成。

還有個比較現實的問題：

一些經驗豐富的開發人員大部分都變成了管理人員，程式碼經常是由一些缺少經驗的程式設計師寫出來的，如果沒有接受相關的培訓，寫出來的SQL效能可想而知。不同的SQL寫法，效率也是有很多差別的，這些套路如果不掌握，SQL不但慢，而且是資源殺手。

很多客戶遇到系統壓力大，首先想到的是更換高級別的伺服器和儲存（很多單個SQL的優化帶來的效能提升可以達到幾百上千倍，這是換任何高階伺服器和儲存都無法實現的），或者是考慮分表、分庫，這些辦法需要耗費大量的人力和財力（當然對拉動GDP很有幫助）。其實大部分情況下做個優化就好了。

說了這麼多，都只是想讓大家（主要是DBA和研發人員，基本上很少有領導關注這種純技術的公眾號）重視優化，如果你願意做個優秀的消防員表現給領導看，或者希望為拉動GDP多做貢獻，那麼可以忽略上面我說的話。

原文來自：老虎劉談SQL優化