分庫分表、分區能解決很多的問題，這也是我們在優化的時候常常聽到的一些可行的方案，不過提到優化就來分庫分表是不是不太合適，本文所闡述的就是分庫分表、分區，什麼時候用，應該怎麼用，怎麼選擇。
話題起點
最近聽到一些學員的面試複述，基本很多的人去面試的時候都會碰到要對MySQL進行優化這樣的題目，很多學員很有經驗的學員也在這上面栽了跟頭。基本回答有幾種
- 加索引
- 分庫分表
- 分區
- 讀寫分離
- 冷熱數據處理
採坑分析
上面的幾點，其實能夠想到的情況下，看似是不錯的。而且很多人也覺得這是標準答案。從表面上看，確實沒有很大的問題，實實在在的解決了一些性能問題。不過很多人對這些東西所帶來的問題並沒有高清楚，同時有些技術在數據庫性能不同的階段是否適合，這個是一個必須要考慮的問題。
採坑的幾個點總結如下:
- 籠統的去描述優化，根本不知道使用的優化策略到底是不是適合的。這個問題在商業開發中很容易出現重大事故
- 如果只考慮這幾點，其實是不太夠的，我們還需要考慮磁盤、成本、IO等問題。這個問題商業開發中也是會出現，同時也會極大的增加投入成本
- 對代碼的優化也是必要的，很多的時候，代碼、SQL的優化能給我們帶來很好的效益，不過這一點對程序員的要求相對較高。商業開發中，很多地方是能跑的就不要動，要是搞不好會全面迴歸。
這幾個點其實都是我們真正做優化的時候需要考慮的。
優化策略分析--索引
索引基本上是我們最常見的一個優化手段了，在單表數據量大的時候如果查詢很慢，對我們的條件加一個索引基本是一個很常規的操作。
- 相信對於重複度很低的字段建索引這錯應該是沒人犯的，不過很多人卻會跳另外一個坑：索引過多、或者索引樹過高。這個問題比較無奈，如果說多索引合併成爲聯合索引能解決根本問題嗎？多數這種情況下不是說沒有辦法解決，而是歷史遺留問題限制。如果強行合併，解決了索引過多的問題，代碼的問題隨之可能就會出現。因爲你合併索引，可能導致原有邏輯產生索引失效的問題。
優化策略分析--分庫分表
一上來就說分庫分表一定要自信看看這一條。分庫分表最大的問題在於對原有數據層的影響，基本這種影響是顛覆性的。如果你將分庫分表加上，分庫分表最直接的就是會讓你對老代碼的維護工作量暴增。當然，這裏的前提是你是做老項目優化。
優化策略分析--分區
MySQL單表能做1024個分區，單庫基本能存幾十個億的表。每個分區算一個表，把所有表都做成分區表看似都是可能的。
- 確確實實，在商業開發當中，分區是一個很重要的優化手段。分區能給我們帶來什麼：用單表存儲億級的數據而不會產生查詢時間過長，清理表也很方便。
- 缺點：分區帶來了很好的用戶體驗，但是隨之而來的就是龐大的運維工作量。試想一下，假若我們一個項目核心表差不多100張，每張建365個分區。總共算下來，分區就會有36500個。相當於我每天要去維護100個表。
優化策略分析--讀寫分離
讀寫分離，基本是目前商業開發最可靠的手段了。讓我們有了更好的數據查詢效率。最大的缺陷在於讀寫分離會增加MySQL服務器的預算。同時MySQL在高併發的情況下，slave也會有延遲，錯誤等。
優化策略分析--冷熱數據處理
冷熱數據的分離，其實對於很多項目來講，是減輕MySQL負擔的一個很好的策略。能給保障MySQL數據庫性能一直良好。
它的問題在於對於某些業務，不能區分冷熱界限。同時冷熱數據也會在某些場景下產生，人工維護的工作。