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

極客們，請收下2021 微軟 x 英特爾黑客松大賽英雄帖！>>>

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

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

加索引

分庫分表

分區

讀寫分離

冷熱資料處理

上面的幾點，其實能夠想到的情況下，看似是不錯的。而且很多人也覺得這是标準答案。從表面上看，确實沒有很大的問題，實實在在的解決了一些性能問題。不過很多人對這些東西所帶來的問題并沒有高清楚，同時有些技術在資料庫性能不同的階段是否适合，這個是一個必須要考慮的問題。 采坑的幾個點總結如下:

籠統的去描述優化，根本不知道使用的優化政策到底是不是适合的。這個問題在商業開發中很容易出現重大事故

如果隻考慮這幾點，其實是不太夠的，我們還需要考慮磁盤、成本、IO等問題。這個問題商業開發中也是會出現，同時也會極大的增加投入成本

對代碼的優化也是必要的，很多的時候，代碼、SQL的優化能給我們帶來很好的效益，不過這一點對程式員的要求相對較高。商業開發中，很多地方是能跑的就不要動，要是搞不好會全面回歸。

這幾個點其實都是我們真正做優化的時候需要考慮的。

索引基本上是我們最常見的一個優化手段了，在單表資料量大的時候如果查詢很慢，對我們的條件加一個索引基本是一個很正常的操作。

相信對于重複度很低的字段建索引這錯應該是沒人犯的，不過很多人卻會跳另外一個坑：索引過多、或者索引樹過高。這個問題比較無奈，如果說多索引合并成為聯合索引能解決根本問題嗎？多數這種情況下不是說沒有辦法解決，而是曆史遺留問題限制。如果強行合并，解決了索引過多的問題，代碼的問題随之可能就會出現。因為你合并索引，可能導緻原有邏輯産生索引失效的問題。

一上來就說分庫分表一定要自信看看這一條。分庫分表最大的問題在于對原有資料層的影響，基本這種影響是颠覆性的。如果你将分庫分表加上，分庫分表最直接的就是會讓你對老代碼的維護工作量暴增。當然，這裡的前提是你是做老項目優化。

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

确确實實，在商業開發當中，分區是一個很重要的優化手段。分區能給我們帶來什麼：用單表存儲億級的資料而不會産生查詢時間過長，清理表也很友善。

缺點：分區帶來了很好的使用者體驗，但是随之而來的就是龐大的運維工作量。試想一下，假若我們一個項目核心表差不多100張，每張建365個分區。總共算下來，分區就會有36500個。相當于我每天要去維護100個表。

讀寫分離，基本是目前商業開發最可靠的手段了。讓我們有了更好的資料查詢效率。最大的缺陷在于讀寫分離會增加MySQL伺服器的預算。同時MySQL在高并發的情況下，slave也會有延遲，錯誤等。

冷熱資料的分離，其實對于很多項目來講，是減輕MySQL負擔的一個很好的政策。能給保障MySQL資料庫性能一直良好。 它的問題在于對于某些業務，不能區分冷熱界限。同時冷熱資料也會在某些場景下産生，人工維護的工作。