《關于數據庫優化的一些感想和建議》要點：
本文介紹了關于數據庫優化的一些感想和建議，希望對您有用。如果有疑問，可以聯系我們。
今天不寫優化,說點感想和建議(昨天就要發的,結果第一次用手機操作,發錯了,只發出去一張網上找的美圖)：
在oracle做研發和售后這么多年,為很多大客戶的數據庫做了優化,這些客戶的系統都是非常重要的系統,而且都配備了非常專業的DBA(或者聘請了業界知名的第三方維護團隊),但是查出來的性能問題還是觸目驚心(第一次優化前都是抱著試試看的態度,看了優化報告才知道問題有多嚴重,系統還有那么多的優化空間),可想而知其他中小客戶的系統面臨的是一個什么情況.
“系統慢不是問題,只要不崩潰就行”,可能這是大多數DBA的想法.
但是,如果你的系統經常出一些故障(硬件問題除外,不過如果磁盤經常壞,應該也和性能有關),很多時候就是因為：沒有使用綁定變量、錯誤的設置了一些優化器參數、并發過大、缺少索引(最普遍)、統計信息不準確、SQL寫法不佳、RAC系統按照單節點設計等等一系列性能問題,導致系統壓力過大而出現的狀況.
但是好多人寧愿出故障時救火,卻不愿意花時間去優化數據庫.試想如果你的系統經過全面優化,負載很小,還會經常出各種問題嗎?
100%的數據庫都是可以優化的,CPU降低,資源爭用小,系統就會更加穩定；IO壓力降低,SQL執行速度加快,磁盤壽命也會更長.
現在的普遍問題是：
大部分DBA對數據庫的優化還只停留在參數調整上,而參數調整能帶來的優化效果一般是非常小的(除非遇到嚴重錯誤的參數設置),而且經常因為改了一些參數導致性能更差.AWR報告更是基本不看.還有一些水平高一些的DBA,認為自己管理的庫已經沒啥好優化的,實際上還是問題一大堆.
好的DBA應該能發現SQL性能問題,將問題反饋給研發,更高一個層次的還會將如何改進告訴研發人員.
而研發人員基本上為了實現功能就已經焦頭爛額了,如果SQL執行的不是非常慢,根本不會考慮其性能問題,只有在效率實在無法接受時,才會想盡各種辦法(分步、分區、分表、并發)讓業務得以在要求的時間內完成.
還有個比較現實的問題：
一些經驗豐富的開發人員大部分都變成了管理人員,代碼經常是由一些缺少經驗的程序員寫出來的,如果沒有接受相關的培訓,寫出來的SQL性能可想而知.不同的SQL寫法,效率也是有很多差別的,這些套路如果不掌握,SQL不但慢,而且是資源殺手.
很多客戶遇到系統壓力大,首先想到的是更換高級別的服務器和存儲(很多單個SQL的優化帶來的性能提升可以達到幾百上千倍,這是換任何高級服務器和存儲都無法實現的),或者是考慮分表、分庫,這些辦法需要耗費大量的人力和財力(當然對拉動GDP很有幫助).其實大部分情況下做個優化就好了.
說了這么多,都只是想讓大家(主要是DBA和研發人員,基本上很少有領導關注這種純技術的公眾號)重視優化,如果你愿意做個優秀的消防員表現給領導看,或者希望為拉動GDP多做貢獻,那么可以忽略上面我說的話.
原文來自：老虎劉談SQL優化
