DBA群體往往都很固執，甚至有些人會有執念。執念有時候是好東西，比如在探究問題的根本的時候，不過有時候會產生一些副作用。最典型的就是對某件事或者問題產生偏見，從而無法正確的思考問題，在探討一個數據庫問題的原因和解決方案的時候尤其如此。我們總是覺得自己找出的線索鏈條是正確的，自己提出的方案才是最好的解決方案。事實上，有些事情可能像一枚硬幣一樣，有兩個面，甚至有多個面，而我們熟知或者掌握的都只是其中的一部分，都是片面的，局部的。因此在判斷一件事情的時候，你可以堅持你的觀點，但是不要急于否定別人的觀點，因為有可能二者都是有道理的。

在某些觀點方面，你可以有立場，可以站邊，但是你不要輕易的去否定別人的觀點。就像PG和MySQL數據庫哪個更好的問題上，我總是和客戶說選擇哪種數據庫，是要根據你自己的自身情況和應用場景的，但是如果你讓我推薦的話，我更傾向于推薦PG，因為我對PG更熟悉一些，如果你用了PG，今后我可以更好的為你服務。這僅僅是從我個人的立場出發，并不是說我就認為PG遠遠好于MySQL。

在定位某個問題的原因的時候，我們往往無法定位到根因，無法從根本上解決問題。因此能夠解決某個問題的方案可能有很多種，這些方案之間有可能不是嚴格意義上存在哪個更好的問題。在這種情況下，我們也會更加傾向于采用自己熟悉的或者自己認為比較合適的方案。DBA往往希望開發商通過修改SQL來解決問題，而開發人員認為數據庫就應該能夠讓他們可以任意寫SQL來實現業務邏輯。在大多數DBA看來，就是開發人員瞎寫垃圾SQL導致了系統總出問題，而從研發人員的立場上看，這個問題的癥結是數據庫太垃圾了。

在了解了問題的多面性和解決路徑的多樣性之后，我們還要注意的一個問題是我們解決問題的環境中，總是有一些條件限制的。十多年前，我在《DBA優化日記》里介紹了一個優化項目的全過程。有朋友和我探討這個案例，認為這是我編出來的一個故事，里面設定了很多預設條件，比如服務器不能擴容，SQL無法大規模修改等。實際上這是一個真的不能再真的案例了，當這本書出版后。書中的一些當事人紛紛和我聯系，感謝我把這個故事講了出來。因為在實際的工作中，我們總是會遇到各種各樣的限制條件，因此我們在考慮問題的解決方案的時候，還需要根據限制條件去裁剪解決路徑。

一個最典型的問題是，既然絕大多數數據庫的問題都與SQL與SQL的負載有關，為什么不從SQL與應用入手，徹底解決數據庫的問題呢？確實在30多年前，我們解決問題的方案就是這樣的，通過研發人員對應用的優化，可以讓資源有限的小型機與數據庫跑得很棒。現在的一些互聯網企業現在也是這么做的。不過要想做好這一點并不容易，30多年的程序員都是“精英”，而那時候我們的軟件產業規模也不大，這些精英足以支撐這個行業。而隨著信息化的發展，軟件產業的規模已經擴大了萬倍了，我們現在無法保證軟件開發人員都是能寫算法來解決復雜問題的“精英”，那么我們就只能容忍應用系統存在不合理的架構，不合理的設計，存在大量比較爛的SQL了。

這種情況下，就需要數據庫系統能夠補上應用比較爛的短板。實際上這幾十年數據庫廠商的目標也是盡可能讓應用開發變得更加簡單，讓應用開發者僅僅關注與業務邏輯。而DBA就是數據庫與應用開發者之間的橋梁，他們通過優化數據庫本身的配置，或者在數據庫中采用數據庫的手段去優化SQL，讓數據庫能夠充分的利用底層的系統資源，跑得更加流暢。

舉個例子，為什么SQL都可以通過開發修改，還需要在數據庫中提供hint,outlines，sql profile ,sql baseline等優化手段呢？實際上這些SQL優化技術的實現模式不同，應用場景也各有不同。Hint是在應明確了某種訪問路徑是最優的情況下固化SQL執行計劃的方法，可以最有效的解決SQL執行計劃錯誤的問題。不過當臨時發現系統存在SQL執行計劃錯誤的時候，修改應用可能至少需要幾個小時，而業務系統需要立即恢復的時候，我們就可以使用outlines，在不修改應用的前提下強制指定SQL的訪問路徑。

似乎hint/outlines已經能夠解決靜態和動態兩方面的問題了，二者組合應該夠用了吧。事實上還不夠，因為有些時候某條SQL在代入不同參數的時候，有兩種截然不同的最佳訪問路徑，那么使用hint/outlines來固化為某種訪問方式就不合適了，因為無論如何，都會出現一種錯誤的執行計劃。這個時候，就需要使用sql profile來解決這個問題了，你可以通過sql profile來讓SQL PLAN生成得更加合理，而不是簡單的指定某種執行計劃。

實際上，前陣子有個數據庫廠商的研發人員與我探討過這個問題，他們的產品已經支持了hint和outlines，正在糾結是不是要支持類似Oracle SQL PROFILE的功能，他們覺得有了前者SQL PROFILE似乎用處不是很大了。

實際上又回到了本文開頭我們探討的那個問題了，在實際的應用場景中，解決某些問題的時候，總是會受到某種限制，因此用戶需要有更多的方案選擇，才能在實際工作中用最小的代價來解決問題。有些時候，解決問題的方法土了一點，可能在某些DBA眼里缺乏技術高度，不過也沒關系，好用就行，能解決問題就行。