隨著使用者數的不斷增加，以及資料量的不斷增加，通過分庫與分表的方式提高查詢效能的同時，帶來了一系列分散式困境。
原文地址：服務端指南 資料儲存篇 | MySQL（09） 分庫與分錶帶來的分散式困境與應對之策
部落格地址：blog.720ui.com/
資料遷移與擴容問題
前面介紹到水平分表策略歸納總結為隨機分表和連續分表兩種情況。連續分表有可能存在資料熱點的問題，有些表可能會被頻繁地查詢從而造成較大壓力，熱資料的表就成為了整個庫的瓶頸，而有些表可能存的是歷史資料，很少需要被查詢到。連續分表的另外一個好處在於比較容易，不需要考慮遷移舊的資料，只需要新增分表就可以自動擴容。隨機分表的資料相對比較均勻，不容易出現熱點和併發訪問的瓶頸。但是，分表擴充套件需要遷移舊的資料。
針對於水平分表的設計至關重要，需要評估中短期內業務的增長速度，對當前的資料量進行容量規劃，綜合成本因素，推算出大概需要多少分片。對於資料遷移的問題，一般做法是通過程式先讀出資料，然後按照指定的分表策略再將資料寫入到各個分表中。
表關聯問題
在單庫單表的情況下，聯合查詢是非常容易的。但是，隨著分庫與分表的演變，聯合查詢就遇到跨庫關聯和跨表關係問題。在設計之初就應該儘量避免聯合查詢，可以通過程式中進行拼裝，或者通過反正規化化設計進行規避。
分頁與排序問題
一般情況下，列表分頁時需要按照指定欄位進行排序。在單庫單表的情況下，分頁和排序也是非常容易的。但是，隨著分庫與分表的演變，也會遇到跨庫排序和跨表排序問題。為了最終結果的準確性，需要在不同的分表中將資料進行排序並返回，並將不同分表返回的結果集進行彙總和再次排序，最後再返回給使用者。
分散式事務問題
隨著分庫與分表的演變，一定會遇到分散式事務問題，那麼如何保證資料的一致性就成為一個必須面對的問題。目前，分散式事務並沒有很好的解決方案，難以滿足資料強一致性，一般情況下，使儲存資料儘可能達到使用者一致，保證系統經過一段較短的時間的自我恢復和修正，資料最終達到一致。
分散式全域性唯一ID
在單庫單表的情況下，直接使用資料庫自增特性來生成主鍵ID，這樣確實比較簡單。在分庫分表的環境中，資料分佈在不同的分表上，不能再借助資料庫自增長特性。需要使用全域性唯一 ID，例如 UUID、GUID等。關於如何選擇合適的全域性唯一 ID，我會在後面的章節中進行介紹。
總結
分庫與分表主要用於應對當前網際網路常見的兩個場景：海量資料和高併發。然而，分庫與分表是一把雙刃劍，雖然很好的應對海量資料和高併發對資料庫的衝擊和壓力，但是卻提高的系統的複雜度和維護成本。
因此，我的建議：需要結合實際需求，不宜過度設計，在專案一開始不採用分庫與分表設計，而是隨著業務的增長，在無法繼續優化的情況下，再考慮分庫與分表提高系統的效能。
（完）
更多精彩文章，盡在「服務端思維」微信公眾號！