《關(guān)于數(shù)據(jù)庫優(yōu)化的一些感想和建議》要點：
本文介紹了關(guān)于數(shù)據(jù)庫優(yōu)化的一些感想和建議，希望對您有用。如果有疑問，可以聯(lián)系我們。

今天不寫優(yōu)化,說點感想和建議(昨天就要發(fā)的,結(jié)果第一次用手機(jī)操作,發(fā)錯了,只發(fā)出去一張網(wǎng)上找的美圖)：

在oracle做研發(fā)和售后這么多年,為很多大客戶的數(shù)據(jù)庫做了優(yōu)化,這些客戶的系統(tǒng)都是非常重要的系統(tǒng),而且都配備了非常專業(yè)的DBA(或者聘請了業(yè)界知名的第三方維護(hù)團(tuán)隊),但是查出來的性能問題還是觸目驚心(第一次優(yōu)化前都是抱著試試看的態(tài)度,看了優(yōu)化報告才知道問題有多嚴(yán)重,系統(tǒng)還有那么多的優(yōu)化空間),可想而知其他中小客戶的系統(tǒng)面臨的是一個什么情況.

“系統(tǒng)慢不是問題,只要不崩潰就行”,可能這是大多數(shù)DBA的想法.

但是,如果你的系統(tǒng)經(jīng)常出一些故障(硬件問題除外,不過如果磁盤經(jīng)常壞,應(yīng)該也和性能有關(guān)),很多時候就是因為：沒有使用綁定變量、錯誤的設(shè)置了一些優(yōu)化器參數(shù)、并發(fā)過大、缺少索引(最普遍)、統(tǒng)計信息不準(zhǔn)確、SQL寫法不佳、RAC系統(tǒng)按照單節(jié)點設(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ù)庫的優(yōu)化還只停留在參數(shù)調(diào)整上,而參數(shù)調(diào)整能帶來的優(yōu)化效果一般是非常小的(除非遇到嚴(yán)重錯誤的參數(shù)設(shè)置),而且經(jīng)常因為改了一些參數(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不但慢,而且是資源殺手.

很多客戶遇到系統(tǒng)壓力大,首先想到的是更換高級別的服務(wù)器和存儲(很多單個SQL的優(yōu)化帶來的性能提升可以達(dá)到幾百上千倍,這是換任何高級服務(wù)器和存儲都無法實現(xiàn)的),或者是考慮分表、分庫,這些辦法需要耗費大量的人力和財力(當(dāng)然對拉動GDP很有幫助).其實大部分情況下做個優(yōu)化就好了.

說了這么多,都只是想讓大家(主要是DBA和研發(fā)人員,基本上很少有領(lǐng)導(dǎo)關(guān)注這種純技術(shù)的公眾號)重視優(yōu)化,如果你愿意做個優(yōu)秀的消防員表現(xiàn)給領(lǐng)導(dǎo)看,或者希望為拉動GDP多做貢獻(xiàn),那么可以忽略上面我說的話.

原文來自：老虎劉談SQL優(yōu)化

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/1949.html