在為很多大客戶的數(shù)據(jù)庫系統(tǒng)調(diào)優(yōu)工作中，雖然這些客戶的系統(tǒng)都都配備了非常專業(yè)的DBA（或者聘請了業(yè)界知名的第三方維護(hù)團(tuán)隊），但是查出來的性能問題還是觸目驚心（第一次優(yōu)化時，查看了優(yōu)化報告才知道問題有多嚴(yán)重，系統(tǒng)還有那么多的優(yōu)化空間），可想而知其他中小客戶的數(shù)據(jù)庫系統(tǒng)面臨的是一個什么情況。
“系統(tǒng)慢不是問題，只要不崩潰就行”，可能這是大多數(shù)DBA的想法。但是在日常使用過程中，你的數(shù)據(jù)庫系統(tǒng)經(jīng)常出一些故障（硬件問題除外，不過如果磁盤經(jīng)常壞，應(yīng)該也和性能有關(guān)），很多時候就是因為：沒有使用綁定變量、錯誤的設(shè)置了一些優(yōu)化器參數(shù)、并發(fā)過大、缺少索引（最普遍）、統(tǒng)計信息不準(zhǔn)確、SQL寫法不佳、RAC系統(tǒng)按照單節(jié)點(diǎn)設(shè)計等等一系列性能問題，而導(dǎo)致系統(tǒng)壓力過大而出現(xiàn)的狀況。可是好多人寧愿出故障時救火，卻不愿意花時間去優(yōu)化數(shù)據(jù)庫。試想如果你的系統(tǒng)經(jīng)過全面優(yōu)化，負(fù)載很小，還會經(jīng)常出各種問題嗎？
100%的數(shù)據(jù)庫都是可以優(yōu)化的，CPU降低，資源爭用小，系統(tǒng)就會更加穩(wěn)定；IO壓力降低，SQL執(zhí)行速度加快，磁盤壽命也會更長。
現(xiàn)在的普遍問題是：大部分DBA對數(shù)據(jù)庫調(diào)優(yōu)還只停留在優(yōu)化效果非常小的參數(shù)調(diào)整上（除非遇到嚴(yán)重錯誤的參數(shù)設(shè)置），甚至經(jīng)常出現(xiàn)因為改了一些參數(shù)導(dǎo)致性能更差。AWR報告更是基本不看。還有一些水平高一些的DBA，認(rèn)為自己管理的庫已經(jīng)沒啥好優(yōu)化的，實際上還是問題一大堆。好的DBA應(yīng)該能發(fā)現(xiàn)SQL性能問題，將問題反饋給研發(fā)，更高一個層次的還會將如何改進(jìn)告訴研發(fā)人員。而研發(fā)人員基本上為了實現(xiàn)功能就已經(jīng)焦頭爛額了，如果SQL執(zhí)行的不是非常慢，根本不會考慮其性能問題，只有在效率實在無法接受時，才會想盡各種辦法（分步、分區(qū)、分表、并發(fā)）讓業(yè)務(wù)得以在要求的時間內(nèi)完成。
還有個比較現(xiàn)實的問題：一些經(jīng)驗豐富的開發(fā)人員大部分都變成了管理人員，代碼經(jīng)常是由一些缺少經(jīng)驗的程序員寫出來的，如果沒有接受相關(guān)的培訓(xùn)，寫出來的SQL性能可想而知。不同的SQL寫法，效率也是有很多差別的，這些套路如果不掌握，SQL不但慢，而且是資源殺手。
由此導(dǎo)致很多客戶遇到系統(tǒng)壓力大時，直接想到的是更換高級別的服務(wù)器和存儲，但其實很多數(shù)據(jù)庫系統(tǒng)只要進(jìn)行性能調(diào)優(yōu)，即可帶來的性能提升可以達(dá)到幾百上千倍，這是也是換任何高級服務(wù)器和存儲都無法實現(xiàn)的。
其實以上所說的，都只是想讓大家（主要是DBA和研發(fā)人員，基本上很少有領(lǐng)導(dǎo)關(guān)注這種純技術(shù)的公眾號）知道數(shù)據(jù)庫系統(tǒng)調(diào)優(yōu)的必要性，如果你愿意做個優(yōu)秀的消防員表現(xiàn)給領(lǐng)導(dǎo)看，或者希望為拉動GDP多做貢獻(xiàn)，那么可以忽略上面我說的話。
