DBA群體往往都很固執(zhí)，甚至有些人會(huì)有執(zhí)念。執(zhí)念有時(shí)候是好東西，比如在探究問(wèn)題的根本的時(shí)候，不過(guò)有時(shí)候會(huì)產(chǎn)生一些副作用。最典型的就是對(duì)某件事或者問(wèn)題產(chǎn)生偏見(jiàn)，從而無(wú)法正確的思考問(wèn)題，在探討一個(gè)數(shù)據(jù)庫(kù)問(wèn)題的原因和解決方案的時(shí)候尤其如此。我們總是覺(jué)得自己找出的線索鏈條是正確的，自己提出的方案才是最好的解決方案。事實(shí)上，有些事情可能像一枚硬幣一樣，有兩個(gè)面，甚至有多個(gè)面，而我們熟知或者掌握的都只是其中的一部分，都是片面的，局部的。因此在判斷一件事情的時(shí)候，你可以堅(jiān)持你的觀點(diǎn)，但是不要急于否定別人的觀點(diǎn)，因?yàn)橛锌赡芏叨际怯械览淼摹?/p>

在某些觀點(diǎn)方面，你可以有立場(chǎng)，可以站邊，但是你不要輕易的去否定別人的觀點(diǎn)。就像PG和MySQL數(shù)據(jù)庫(kù)哪個(gè)更好的問(wèn)題上，我總是和客戶說(shuō)選擇哪種數(shù)據(jù)庫(kù)，是要根據(jù)你自己的自身情況和應(yīng)用場(chǎng)景的，但是如果你讓我推薦的話，我更傾向于推薦PG，因?yàn)槲覍?duì)PG更熟悉一些，如果你用了PG，今后我可以更好的為你服務(wù)。這僅僅是從我個(gè)人的立場(chǎng)出發(fā)，并不是說(shuō)我就認(rèn)為PG遠(yuǎn)遠(yuǎn)好于MySQL。

在定位某個(gè)問(wèn)題的原因的時(shí)候，我們往往無(wú)法定位到根因，無(wú)法從根本上解決問(wèn)題。因此能夠解決某個(gè)問(wèn)題的方案可能有很多種，這些方案之間有可能不是嚴(yán)格意義上存在哪個(gè)更好的問(wèn)題。在這種情況下，我們也會(huì)更加傾向于采用自己熟悉的或者自己認(rèn)為比較合適的方案。DBA往往希望開(kāi)發(fā)商通過(guò)修改SQL來(lái)解決問(wèn)題，而開(kāi)發(fā)人員認(rèn)為數(shù)據(jù)庫(kù)就應(yīng)該能夠讓他們可以任意寫SQL來(lái)實(shí)現(xiàn)業(yè)務(wù)邏輯。在大多數(shù)DBA看來(lái)，就是開(kāi)發(fā)人員瞎寫垃圾SQL導(dǎo)致了系統(tǒng)總出問(wèn)題，而從研發(fā)人員的立場(chǎng)上看，這個(gè)問(wèn)題的癥結(jié)是數(shù)據(jù)庫(kù)太垃圾了。

在了解了問(wèn)題的多面性和解決路徑的多樣性之后，我們還要注意的一個(gè)問(wèn)題是我們解決問(wèn)題的環(huán)境中，總是有一些條件限制的。十多年前，我在《DBA優(yōu)化日記》里介紹了一個(gè)優(yōu)化項(xiàng)目的全過(guò)程。有朋友和我探討這個(gè)案例，認(rèn)為這是我編出來(lái)的一個(gè)故事，里面設(shè)定了很多預(yù)設(shè)條件，比如服務(wù)器不能擴(kuò)容，SQL無(wú)法大規(guī)模修改等。實(shí)際上這是一個(gè)真的不能再真的案例了，當(dāng)這本書出版后。書中的一些當(dāng)事人紛紛和我聯(lián)系，感謝我把這個(gè)故事講了出來(lái)。因?yàn)樵趯?shí)際的工作中，我們總是會(huì)遇到各種各樣的限制條件，因此我們?cè)诳紤]問(wèn)題的解決方案的時(shí)候，還需要根據(jù)限制條件去裁剪解決路徑。

一個(gè)最典型的問(wèn)題是，既然絕大多數(shù)數(shù)據(jù)庫(kù)的問(wèn)題都與SQL與SQL的負(fù)載有關(guān)，為什么不從SQL與應(yīng)用入手，徹底解決數(shù)據(jù)庫(kù)的問(wèn)題呢？確實(shí)在30多年前，我們解決問(wèn)題的方案就是這樣的，通過(guò)研發(fā)人員對(duì)應(yīng)用的優(yōu)化，可以讓資源有限的小型機(jī)與數(shù)據(jù)庫(kù)跑得很棒?，F(xiàn)在的一些互聯(lián)網(wǎng)企業(yè)現(xiàn)在也是這么做的。不過(guò)要想做好這一點(diǎn)并不容易，30多年的程序員都是“精英”，而那時(shí)候我們的軟件產(chǎn)業(yè)規(guī)模也不大，這些精英足以支撐這個(gè)行業(yè)。而隨著信息化的發(fā)展，軟件產(chǎn)業(yè)的規(guī)模已經(jīng)擴(kuò)大了萬(wàn)倍了，我們現(xiàn)在無(wú)法保證軟件開(kāi)發(fā)人員都是能寫算法來(lái)解決復(fù)雜問(wèn)題的“精英”，那么我們就只能容忍應(yīng)用系統(tǒng)存在不合理的架構(gòu)，不合理的設(shè)計(jì)，存在大量比較爛的SQL了。

這種情況下，就需要數(shù)據(jù)庫(kù)系統(tǒng)能夠補(bǔ)上應(yīng)用比較爛的短板。實(shí)際上這幾十年數(shù)據(jù)庫(kù)廠商的目標(biāo)也是盡可能讓應(yīng)用開(kāi)發(fā)變得更加簡(jiǎn)單，讓應(yīng)用開(kāi)發(fā)者僅僅關(guān)注與業(yè)務(wù)邏輯。而DBA就是數(shù)據(jù)庫(kù)與應(yīng)用開(kāi)發(fā)者之間的橋梁，他們通過(guò)優(yōu)化數(shù)據(jù)庫(kù)本身的配置，或者在數(shù)據(jù)庫(kù)中采用數(shù)據(jù)庫(kù)的手段去優(yōu)化SQL，讓數(shù)據(jù)庫(kù)能夠充分的利用底層的系統(tǒng)資源，跑得更加流暢。

舉個(gè)例子，為什么SQL都可以通過(guò)開(kāi)發(fā)修改，還需要在數(shù)據(jù)庫(kù)中提供hint,outlines，sql profile ,sql baseline等優(yōu)化手段呢？實(shí)際上這些SQL優(yōu)化技術(shù)的實(shí)現(xiàn)模式不同，應(yīng)用場(chǎng)景也各有不同。Hint是在應(yīng)明確了某種訪問(wèn)路徑是最優(yōu)的情況下固化SQL執(zhí)行計(jì)劃的方法，可以最有效的解決SQL執(zhí)行計(jì)劃錯(cuò)誤的問(wèn)題。不過(guò)當(dāng)臨時(shí)發(fā)現(xiàn)系統(tǒng)存在SQL執(zhí)行計(jì)劃錯(cuò)誤的時(shí)候，修改應(yīng)用可能至少需要幾個(gè)小時(shí)，而業(yè)務(wù)系統(tǒng)需要立即恢復(fù)的時(shí)候，我們就可以使用outlines，在不修改應(yīng)用的前提下強(qiáng)制指定SQL的訪問(wèn)路徑。

似乎hint/outlines已經(jīng)能夠解決靜態(tài)和動(dòng)態(tài)兩方面的問(wèn)題了，二者組合應(yīng)該夠用了吧。事實(shí)上還不夠，因?yàn)橛行r(shí)候某條SQL在代入不同參數(shù)的時(shí)候，有兩種截然不同的最佳訪問(wèn)路徑，那么使用hint/outlines來(lái)固化為某種訪問(wèn)方式就不合適了，因?yàn)闊o(wú)論如何，都會(huì)出現(xiàn)一種錯(cuò)誤的執(zhí)行計(jì)劃。這個(gè)時(shí)候，就需要使用sql profile來(lái)解決這個(gè)問(wèn)題了，你可以通過(guò)sql profile來(lái)讓SQL PLAN生成得更加合理，而不是簡(jiǎn)單的指定某種執(zhí)行計(jì)劃。

實(shí)際上，前陣子有個(gè)數(shù)據(jù)庫(kù)廠商的研發(fā)人員與我探討過(guò)這個(gè)問(wèn)題，他們的產(chǎn)品已經(jīng)支持了hint和outlines，正在糾結(jié)是不是要支持類似Oracle SQL PROFILE的功能，他們覺(jué)得有了前者SQL PROFILE似乎用處不是很大了。

實(shí)際上又回到了本文開(kāi)頭我們探討的那個(gè)問(wèn)題了，在實(shí)際的應(yīng)用場(chǎng)景中，解決某些問(wèn)題的時(shí)候，總是會(huì)受到某種限制，因此用戶需要有更多的方案選擇，才能在實(shí)際工作中用最小的代價(jià)來(lái)解決問(wèn)題。有些時(shí)候，解決問(wèn)題的方法土了一點(diǎn)，可能在某些DBA眼里缺乏技術(shù)高度，不過(guò)也沒(méi)關(guān)系，好用就行，能解決問(wèn)題就行。