今天我想對一個Greenfield項目上可以采用的各種性能優(yōu)化策略作個對比。換言之，該項目沒有之前決策強加給它的各種約束限制，也還沒有被優(yōu)化過。

具體來說，我想比較的兩種優(yōu)化策略是優(yōu)化MySQL和緩存。提前指出，這些優(yōu)化是正交的，唯一讓你選擇其中一者而不是另一者的原因是他們都耗費了資源，即開發(fā)時間。

優(yōu)化MySQL時，一般會先查看發(fā)送給mysql的查詢語句，然后運行explain命令。稍加審查后很常見的做法是增加索引或者對模式做一些調(diào)整。

1、一個經(jīng)過優(yōu)化的查詢對于所有使用應用的用戶來說都是快速的。因為索引通過對數(shù)復雜度的速度來檢索數(shù)據(jù)（又名分制，正如你搜索一個電話簿一樣，逐步縮小搜索范圍），而且隨著數(shù)據(jù)量的遞增也能維持良好的性能。對一個未經(jīng)索引化的查詢的結(jié)果做緩存隨著數(shù)據(jù)的增長有時候則可能會表現(xiàn)得更差。隨著數(shù)據(jù)的增長，那些未命中緩存的用戶可能會得到很糟糕的體驗，這樣的應用是不可用的。

2、優(yōu)化MySQL不需要擔心緩存失效或者緩存數(shù)據(jù)過期的問題。

3、優(yōu)化MySQL可以簡化技術(shù)架構(gòu)，在開發(fā)環(huán)境下復制和工作會更加容易。

1、有一些查詢不能光通過索引得到性能上的改善，可能還需要改變模式，在某些情況下這對于一些應用可能會很麻煩。

2、有些模式的更改可能用于反規(guī)范化（數(shù)據(jù)備份）。盡管對于DBA來說，這是一項常用的技術(shù)，它需要所有權(quán)以確保所有的地方都是由應用程序更新，或需要安裝觸發(fā)器來保證這種變化。

3、一些優(yōu)化手段可能是MySQL所特有的。也就是說，如果底層軟件被移植到多個數(shù)據(jù)庫上工作，那么很難確保除了增加索引外一些更復雜的優(yōu)化技術(shù)可以通用。

這種優(yōu)化需要人來分析應用的實際情況，然后將處理代價昂貴的部分從MySQL中剝離出來用第三方緩存替代，比如memcached或Redis。

1、緩存對于一些MySql自身很難優(yōu)化的查詢來說會工作地很好，比如大規(guī)模的聚合或者分組的查詢。

2、緩存對于提高系統(tǒng)的吞吐率來說可能是個不錯的方案。比如對于多人同時訪問應用時響應速度很慢的情況。

3、緩存可能更容易構(gòu)建在另一個應用之上。比如：你的應用可能是另一個用MySQL存儲數(shù)據(jù)的軟件包的前端，而要對這個軟件包做任何數(shù)據(jù)庫方面的改動都非常難。

1、如果數(shù)據(jù)對外提供多種存取范式（例如，在不同的頁面上用不同的形式展示），那么讓緩存過期或者更新可能會很難，同時/或者可能需要容忍已過期的數(shù)據(jù)。一個可行的替代方案是設(shè)計一套更加精細的緩存機制，當然它也有缺點，即多次獲取緩存會增加時延。

2、緩存一個產(chǎn)生代價昂貴的對象對于那些未命中緩存的用戶（見優(yōu)化MySQL的優(yōu)勢#1）而言可能會產(chǎn)生潛在的性能差異。一些好的性能實踐表明你應該盡量縮小用戶之間的差異性，而不僅僅是平均化（緩存傾向于這么做）。

3、幼稚的緩存實現(xiàn)無力應對一些微妙的漏洞，比如雪崩效應。就在上周我?guī)椭艘粋€人，他的數(shù)據(jù)庫服務器被多個試圖同時再生同樣緩存內(nèi)容的用戶請求沖垮。正確的策略是引入一定級別的鎖來將緩存再生的請求序列化。

一般情況下，我會建議用戶先對MySQL進行優(yōu)化，因為這是我認為開始階段最合適的解決方案。但長期來看，大部分應用都會有一些用例需要一定程度上同時實現(xiàn)以上這些方案。

原文鏈接： Morgan Tocker 翻譯： 伯樂在線 - 高磊