所謂武功再高也怕菜刀-分割槽、分庫、分表和分散式的優劣

我相信做過資料庫對以上的都不陌生。基本上主流資料庫都支援分割槽。分割槽是一種對應用透明的管理表方式。儘管可以在網上找不到不少黑MySQL分割槽的，但是時至今日我用MySQL分割槽沒發現一點問題，當然PostgreSQL和Oracle的我也沒發現問題。我猜測那些問題應該來自於使用上的不規範。我以前做公安系統由於單表幾十億上百億，還採用過二級分割槽，效果非常好。

    分割槽一般使用都是按照時間，基本是按照月。比如我一個月一個分割槽，我有5年資料，那麼就是60個分割槽。這個時候如果想把最早的一個月資料歸檔。我們可以採用互動分割槽等技術，秒匯出。然後把這些資料遷移或者壓縮，達到歸檔和給線上資料庫瘦身的效果。如果沒有分割槽會怎麼樣？苦啊，那隻能按照條件邏輯匯出了，這個效率低下。匯出以後delete這些匯出的資料，但是delete不釋放空間呀，又要做碎片整理。好在部分資料庫做起來也不影響業務。我有個資料以前有一個庫Oracle。20多T，碎片有880G。RAID10的陣列，磁碟是15k轉速的。直接線上做碎片整理，不影響業務的條件下做了55個小時。另外一個同事的陣列較差，他悲劇的做了550個小時（快一個月了）。可見分割槽是多麼重要。而很多表設計的時候，由於缺乏設計和規劃，沒有建立成分割槽。那麼就要將非分割槽的錶轉換成分割槽表。怎麼轉換我在之前的公眾號寫過了，感興趣的可以往前翻幾天。但是如果時間不是日期型，這就沒辦法了。可見設計是多麼重要，設計糟糕的前提一下，一切最佳化都無能為力。

   分割槽不好的地方，比如分割槽到了最後一個月，忘記加新的分割槽就報錯了。這點上Oracle做到了自動分割槽，永遠不會出問題。這個特性的確避免了很多故障。不過drop分割槽的時候要帶上update global index，不帶也會出故障。哎，我一直想給官方提，我們們不能drop的時候隱性的帶上嗎？這樣真的能避免故障。

  分割槽另外一個不好的地方就是，我分了60個月的區，結果你查詢的時候不按照時間查，比如前後%，或者不帶條件。那麼等於還是查了60個月。假設這個表不分割槽是600G，分割槽以後總量還是600G。那麼一個SQL查600G，該慢還是慢。分割槽的快是這的是在一個分割槽內查詢會好一點點（不過我實測基本感知不到），也就是說你帶上時間限定在一個分割槽中檢索，不要跨分割槽。其實這個和不分割槽時候帶上一個月的時間差不多的。所以分割槽最大的貢獻我覺得還是生命週期管理。

   分庫一般伴隨著微服務和中臺，原來單體執行挺好的。現在就開始拆，我在老白的一篇微服務資料庫選型中看到，開發一時爽，運維兩行淚。我真實感覺是，開發兩行淚，運維兩行淚。一旦分庫資料互動要麼靠介面要麼靠同步。介面嘛，我接觸的效率都不高，一定比不分庫低。同步嘛，任何CDC使用成本都不低，一點沒問題的沒見過。只能說有的工具做的好，問題少。問題其實大多數也是使用不當造成的。按照一個維度分庫以後，那麼按照其他維度就無法查詢了。和分割槽一樣的道理。如果查所有等於跨所有節點。也和分割槽一樣，該全部還是全部，加上網路更慢了。雖然MySQL和PG以及Oracle這三大主流資料庫在門派上有紛爭，但是對於分庫是一致的看法就是不要分。

  分表必然涉及分庫，分庫不一定涉及分表。就是一個表分成N份，分散在N個節點上。每個節點上儲存N分之一的資料。千萬別相信水平擴充套件，至少我不信。1000萬資料存100個節點。現在資料到2000萬了，要增加100個節點怎麼辦？那是要200個節點資料重新打散。如果做過redis的cluster的就知道，reblance時候是卡主的。所以分表的再平衡要停機的。然後如果也來一個前後%，效果一樣，分開全表掃。（當然這個並行掃能快N倍）

 分散式，我認為MySQL的MGR是分散式，Oracle的RAC也是。TiDB Oceanbase polardb TDSQL這些帶上paxos和raft的都是。當超過單機能力時候，考慮分散式。那麼如果在分散式上是不是可以胡來？比如前後%，答案是否定的。一樣會把分散式搞死。

  總結：分割槽、分庫、分表、分散式都怕不按照規範開發，比如全表。所謂武功再高也怕菜刀。分割槽和分散式可取。但凡做分散式的都是單機玩的好的，比如阿里、騰訊等。單機玩不好的，我絕對不相信能用好分散式。比如單刀都能劃到自己的，雙刀說不定是還沒砍到人，自己已經血流了一地了。分庫 分表，不可取，同樣遇到前後%，就是雪上加霜。