再談資料庫最佳化（database tuning）的真諦和誤區

當今各行業資訊量呈現爆炸式增長，因此，資料庫最佳化也就顯得彌足重要。隨著資料庫效能問題的出現，每位使用者為了解決出現的問題，不得不滿網上到處搜尋最佳化的”靈丹妙藥“和捷徑，於是，就出現了各種各樣的條條框框和金科玉律，以至於這些觀點流傳很廣，對廣大使用者的影響也很大，例如：

1、SQL語句必須怎麼寫和注意什麼才能效能好，某種寫法會比其他寫法效能好。這種說法，雖然不能說完全是錯的，但也不能說是對的。我們看看資料庫最佳化器的演化和發展歷程，就能明白這麼說的原因。低版本的資料庫最佳化器是基於規則（rule）的，所謂基於規則，就是SQL語句的執行計劃是和SQL的語法息息相關的，也就是說，SQL語句的寫法決定了最終的執行計劃，也就決定了該SQL語句的效能狀況。隨著最佳化器的不斷進化和發展，目前所有關係庫的最佳化器都是CBO，也就是基於成本的最佳化器，顧名思義，在這種最佳化器中，SQL語句的執行計劃和寫法幾乎沒什麼關係，而是根據最佳化器計算出的成本來選擇出最好的執行計劃的，哪個執行計劃成本最低，那麼就用哪個執行計劃，因此，效能也最好。不可否認，最先進的關係庫最佳化器，例如：Oracle12c，雖然智慧化程度已經非常高，機制和演算法已經非常先進和完善，產生的執行計劃也不可能100%的是最高效的，其中的因素很多，這裡不意義論述。甚至在某些場景下，SQL語句的寫法確實會影響最終的執行計劃，從而影響SQL語句的效能好壞。

2、我經常聽到現場的使用者驚呼：不好了，資料庫中有鎖。針對這種情況，我曾經一遍遍的和他們講，關係庫中存在鎖是很正常的，在一個高負載、高併發的關係庫中，時時刻刻都會存在一些、甚至大量的鎖，這是關係庫的核心機制，在這種高負載、高併發的資料庫上，有鎖是正常的，沒有鎖是不正常的，所以，資料庫中存在鎖也就不值得奇怪和吃驚了。存在鎖沒什麼奇怪的，關鍵是看看是否正常，那麼，怎麼看鎖是否正常，針對每種關係庫，都有自己一套理論和辦法來查詢和分析，這裡不再贅述。

3、很多使用者對SQL調優（SQL TUNING）情有獨鍾，不管遇到什麼資料庫的問題，都會想到SQL調優上去。確實，SQL調優確實可以在很大程度上改善資料庫的效能，改善幅度也可能是最大的，但在對SQL進行調優前，要看看其他層面或方面是否正常，在確定了效能問題確實是因為SQL引起的，在進行SQL調優，也許才會起到有的放矢，從而起到最好的最佳化作用。除了SQL層面，還有很多層面和方面會影響資料庫效能，例如：OS層面的效能也會影響到資料庫效能，因為它是資料庫的平臺和容器；同時，如果資料庫系統存在問題，單純去進行SQL 調優，可能也是解決不了問題的。OS和DB層面存在問題，導致資料庫效能問題的案例在現實中還是經常會遇到的。所以，在SQL調優前，固定其他層面和方面的因素是必須的。

4、資料庫存在效能問題，經常聽到很多人立刻問道：資料量多大？如果聽說上億或者更大，馬上就說：這麼大資料量，效能當然會有問題，於是乎那些問問題的人馬上就會心服口服。其實這裡面會有錯誤的認識，資料量大是導致出現效能問題的基礎，如果資料庫裡沒資料，也就不會出現效能問題，但即使有幾十億，上百億，上千億資料量，我只取其中的一條或很少部分資料，且計劃正確，也未必就會存在效能問題。也經常有人說，我們上百億資料量，或PB級資料量，能做到毫秒級的速度，這明顯是內行人忽悠外行人，或者外行人忽悠外行人，能不能到毫秒級，和多方面因素有關，還有關鍵看怎麼用資料，有些需求，幾百萬甚至更少就能出現嚴重的效能問題，而有的需求，幾百億上千億，效能也不是問題，但現實中，偏偏很多人被這種說法給說服了，而且心悅誠服的虔誠樣子，每次我對這些類似說法提出質疑，從來沒得到過正面回應。所以，資料量是效能問題的誘因，但非必然。兩本書，一本有幾十頁，另一本有幾千頁，透過目錄去查詢某一章節，速度也許不會真的有數量級的差別，但因為目錄大小不同，效能也許會有點差別，一個道理。

以上僅僅舉出了現實中最常見的幾種情況和誤解，其他類似的情況或案例也許會很多，這裡不再一一贅述。

所謂最佳化，不是條條框框，也不存在金科玉律，而是基於深厚理論基礎，進行豐富實踐的理解和總結，理論和實踐缺一不可。其實，現實中很多行業都是一樣的，最佳化從來不是一個入門級的技術，它是一種熟能生巧，活學活用的技能，因此，對於一個初學者來說，應該打好基礎，不斷實踐，在實踐中不斷總結，積累到一定程度，就能解決一些效能方面的問題，不可否認，最佳化也有一定的技巧和規律可循，但需要基礎才能領會和掌握。

基於個人理解，希望能對大家有所幫助。