【ShardingSphere】作優化上來就分庫分表？請慎重分庫分表

分庫分表、分區能解決不少的問題，這也是咱們在優化的時候經常聽到的一些可行的方案，不過提到優化就來分庫分表是否是不太合適，本文所闡述的就是分庫分表、分區，何時用，應該怎麼用，怎麼選擇。

話題起點

最近聽到一些學員的面試複述，基本不少的人去面試的時候都會碰到要對MySQL進行優化這樣的題目，不少學員頗有經驗的學員也在這上面栽了跟頭。基本回答有幾種

• 加索引
• 分庫分表
• 分區
• 讀寫分離
• 冷熱數據處理

採坑分析

上面的幾點，其實可以想到的狀況下，看似是不錯的。並且不少人也以爲這是標準答案。從表面上看，確實沒有很大的問題，實實在在的解決了一些性能問題。不過不少人對這些東西所帶來的問題並無高清楚，同時有些技術在數據庫性能不一樣的階段是否適合，這個是一個必需要考慮的問題。 採坑的幾個點總結以下:

• 籠統的去描述優化，根本不知道使用的優化策略究竟是不是適合的。這個問題在商業開發中很容易出現重大事故
• 若是隻考慮這幾點，實際上是不太夠的，咱們還須要考慮磁盤、成本、IO等問題。這個問題商業開發中也是會出現，同時也會極大的增長投入成本
• 對代碼的優化也是必要的，不少的時候，代碼、SQL的優化能給咱們帶來很好的效益，不過這一點對程序員的要求相對較高。商業開發中，不少地方是能跑的就不要動，要是搞很差會全面迴歸。

這幾個點其實都是咱們真正作優化的時候須要考慮的。

優化策略分析--索引

索引基本上是咱們最多見的一個優化手段了，在單表數據量大的時候若是查詢很慢，對咱們的條件加一個索引基本是一個很常規的操做。

• 相信對於重複度很低的字段建索引這錯應該是沒人犯的，不過不少人卻會跳另一個坑：索引過多、或者索引樹太高。這個問題比較無奈，若是說多索引合併成爲聯合索引能解決根本問題嗎？多數這種狀況下不是說沒有辦法解決，而是歷史遺留問題限制。若是強行合併，解決了索引過多的問題，代碼的問題隨之可能就會出現。由於你合併索引，可能致使原有邏輯產生索引失效的問題。

優化策略分析--分庫分表

一上來就說分庫分表必定要自信看看這一條。分庫分表最大的問題在於對原有數據層的影響，基本這種影響是顛覆性的。若是你將分庫分表加上，分庫分表最直接的就是會讓你對老代碼的維護工做量暴增。固然，這裏的前提是你是作老項目優化。

優化策略分析--分區

MySQL單表能作1024個分區，單庫基本能存幾十個億的表。每一個分區算一個表，把全部表都作成分區表看似都是可能的。

• 確確實實，在商業開發當中，分區是一個很重要的優化手段。分區能給咱們帶來什麼：用單表存儲億級的數據而不會產生查詢時間過長，清理表也很方便。
• 缺點：分區帶來了很好的用戶體驗，可是隨之而來的就是龐大的運維工做量。試想一下，倘若咱們一個項目核心表差很少100張，每張建365個分區。總共算下來，分區就會有36500個。至關於我天天要去維護100個表。

優化策略分析--讀寫分離

讀寫分離，基本是目前商業開發最可靠的手段了。讓咱們有了更好的數據查詢效率。最大的缺陷在於讀寫分離會增長MySQL服務器的預算。同時MySQL在高併發的狀況下，slave也會有延遲，錯誤等。

優化策略分析--冷熱數據處理

冷熱數據的分離，其實對於不少項目來說，是減輕MySQL負擔的一個很好的策略。能給保障MySQL數據庫性能一直良好。 它的問題在於對於某些業務，不能區分冷熱界限。同時冷熱數據也會在某些場景下產生，人工維護的工做。