高效能是設計出來的

好多時候我主動或者被動參與到一些最佳化的工作中來。有的時候提升較大，比如我在公安行業時候，有一次開發找到我說，他們一天出一個報表，一次15個小時，忍受不了了。問我能不能最佳化到一個小時。我接手以後除了索引（不能僅僅指望索引，但是一點不用也不行），總之N個改進建議以後。最終執行的結果是6秒。15小時到6秒，大約9000倍的提升。當時開發吃驚的嘴都合不上了，但是這才是一個資料庫應有的效率。不少人誤解報表就應該很慢，其實這不一定的。以上這個雖然不是我個人的記錄，但是充分體現了最佳化比起硬體提升的收益之大。不過這裡有個前提條件就是開發不折不扣的按照我的思路去做了。如果我的建議和意見，不採納，不去實施，那一點用也沒有。就會形成“可憐夜半虛前席， 不問蒼生問鬼神。 ” 的結局。

   但是有些系統給了建議也不改，很大程度上是因為，沒法改，因為設計的慘不忍睹，如果說改，還不如推翻重來，接受不了或者做不下來。   “高效能是設計出來的”，DBA圈內的至理名言。反過來說在設計糟糕的情況下一切最佳化都是扯淡。 我講最佳化從來幾乎不講SQL改寫，因為這樣的收效不大。我多年工作發現，幾乎都是設計問題，甚至是需求問題。這個重要嗎？我說重要可能未必大家都認可。多年前幫一個朋友忙，他們公司遇到問題（每週系統都故障至少一次），技術團隊最終定位是由於資料庫引起的。也是託人打聽到我，讓我去看看。我看過以後，指出了問題已經改進方法。技術團隊明白了問題所在，即可開始修改，有的可能是要改實現方式和邏輯。但是他們天天修改到凌晨2-3點，幹了一週。（私人小公司，系統不穩定，營收受到較大影響），所以比較認真對待。經過奮戰以後，結果是再也沒有出過問題，為此特意感謝了我。最後反饋說使用者反饋系統快的有點不適應了。

   一個系統就看是不是自己的命，剛才這個案例中是因為私人小公司，出了問題損失都是自己的。而我挽救了系統的穩定，等於間接的救了公司的“命”。對於已經給了建議不能改的，那麼也沒有辦法。

   那15個小時到6秒是極致嗎？顯然不是，所謂最佳化只能在現有的基礎上做的最大限度改善。 之所以能提升9000倍是設計還不算差，但是如果能按照我的設計的話，那個應該最多2秒就可以了。資料庫設計最重要的是資料型別和表的設計。每個專案和場景都是不一樣的，但是我見過很多的就是把以前專案的表在這裡鋪開就用。最後SQL寫的特別複雜和低下，那是因為用表去適配需求。而我覺得應該是根據需求來設計表，除非需求一模一樣，否則每個專案的表結構都應該不同。表結構設計的差不能用嗎？能，只是效能差。效能差不能用嗎？能，只是不穩定。不穩定要緊嗎？有的要緊，有的不要緊。還是看是不是重視。

   我們很多系統故障不是因為網路中斷或者硬體損壞（這種極少，如果有那說明基礎環境不穩定，基礎環境不穩定的別指望資料庫可以解決），基礎環境的前提條件要去滿足，這些不滿足整改起來還是相對容易的。常年亞健康的資料庫（負荷高的）就像抵抗力弱的人，一旦有風吹草動就可能生病了。這種系統就要平時不斷檢查，要做預警，有的時候儘管有預警但是來的太快，幾秒鐘的時間就已經造成了事故，根本做不出反應。但是免疫力好的（幾乎沒負荷的資料庫），突然來一下十倍，甚至百倍的衝擊依然能抵抗住衝擊，從而保證系統正常執行，在這種情況下，即使沒有來得及做提前預警，無法比使用者早感知，但是還是可以平穩度過。