關係型資料庫本身比較容易成為系統瓶頸，單機儲存容量、連線數、處理能力都有限。當單表的資料量達到1000W或100G以後，由於查詢維度較多，即使新增從庫、優化索引，做很多操作時效能仍下降嚴重。此時就要考慮對其進行切分了，切分的目的就在於減少資料庫的負擔，縮短查詢時間。

資料庫分散式核心內容無非就是資料切分（Sharding），以及切分後對資料的定位、整合。資料切分就是將資料分散儲存到多個數據庫中，使得單一資料庫中的資料量變小，通過擴充主機的數量緩解單一資料庫的效能問題，從而達到提升資料庫操作效能的目的。

• 垂直切分：縱向切分，根據業務耦合性，拆分表或庫
  • 垂直分庫：根據業務耦合性，將關聯度低的不同表儲存在不同的資料庫。做法與大系統拆分為多個小系統類似，按業務分類進行獨立劃分。與"微服務治理"的做法相似，每個微服務使用單獨的一個數據庫。
  • 垂直分表：垂直分表是基於資料庫中的"列"進行，某個表字段較多，可以新建一張擴充套件表，將不經常用或欄位長度較大的欄位拆分出去到擴充套件表中
• 水平切分：橫向切分，通過下標來分庫分表
  • 水平分庫：根據業務鍵拆分為不同庫，庫表結構、表名均相同，資料不同
  • 水平分表：根據業務鍵拆分為不同表，表結構相同，表名不同

垂直切分的優點

• 解決業務系統層面的耦合，業務清晰
• 與微服務的治理類似，也能對不同業務的資料進行分級管理、維護、監控、擴充套件等
• 高併發場景下，垂直切分一定程度的提升IO、資料庫連線數、單機硬體資源的瓶頸

垂直切分的缺點

• 部分表無法join，只能通過介面聚合方式解決，提升了開發的複雜度
• 分散式事務處理複雜
• 依然存在單表資料量過大的問題（需要水平切分）

水平切分的優點

• 不存在單庫資料量過大、高併發的效能瓶頸，提升系統穩定性和負載能力
• 應用端改造較小，不需要拆分業務模組

水平切分的缺點

• 跨分片的事務一致性難以保證
• 跨庫的join關聯查詢效能較差
• 資料多次擴充套件難度和維護量極大

1. 水平切分鍵值選取

根據數值範圍:按照時間區間或ID區間來切分

• 優點
  • 單表大小可控
  • 天然便於水平擴充套件，後期如果想對整個分片叢集擴容時，只需要新增節點即可，無需對其他分片的資料進行遷移
  • 使用分片欄位進行範圍查詢時，連續分片可快速定位分片進行快速查詢，有效避免跨分片查詢的問題。
  • 冷熱資料分離,
  • 切分策略簡單
• 缺點
  • 資料量和請求量不均,熱點資料成為效能瓶頸。連續分片可能存在資料熱點，例如按時間欄位分片，有些分片儲存最近時間段內的資料，可能會被頻繁的讀寫，而有些分片儲存的歷史資料，則很少被查詢
  • uid必須要滿足遞增的特性

hash取模:採用hash取模的切分方式

• 優點
  • 資料分片相對比較均勻，不容易出現熱點和併發訪問的瓶頸
• 缺點
  • 後期分片叢集擴容時，需要遷移舊的資料（使用一致性hash演算法能較好的避免這個問題）
  • 容易面臨跨分片查詢的複雜問題。

2. 拆分帶來的問題

事務一致性問題

• 分散式事務，沒有簡單的方案，一般可使用"XA協議"和"兩階段提交"處理。
• 對於那些效能要求很高，但對一致性要求不高的系統，往往不苛求系統的實時一致性，只要在允許的時間段內達到最終一致性即可，可採用事務補償的方式

跨節點關聯查詢 join 問題

• 全域性表，也可看做是"資料字典表"，就是系統中所有模組都可能依賴的一些表，為了避免跨庫join查詢，可以將這類表在每個資料庫中都儲存一份
• 欄位冗餘:一種典型的反正規化設計，利用空間換時間，為了效能而避免join查詢
• 資料組裝:在系統層面，分兩次查詢，第一次查詢的結果集中找出關聯資料id，然後根據id發起第二次請求得到關聯資料。最後將獲得到的資料進行欄位拼裝。
• ER分片：先確定表之間的關聯關係，並將那些存在關聯關係的表記錄存放在同一個分片上

跨節點分頁、排序、函式問題

• 需要先在不同的分片節點中將資料進行排序並返回，然後將不同分片返回的結果集進行彙總和再次排序，最終返回給使用者

全域性主鍵避重問題

• UUID:UUID是主鍵是最簡單的方案，本地生成，效能高，沒有網路耗時。但缺點也很明顯，由於UUID非常長，會佔用大量的儲存空間；另外，作為主鍵建立索引和基於索引進行查詢時都會存在效能問題
• 結合資料庫維護主鍵ID表

資料遷移、擴容問題

3. 什麼時候考慮切分

能不切分儘量不要切分

不到萬不得已不用輕易使用分庫分表這個大招，避免"過度設計"和"過早優化"

資料量過大，正常運維影響業務訪問

• 對資料庫備份，如果單表太大，備份時需要大量的磁碟IO和網路IO
• 對一個很大的表進行DDL修改時，MySQL會鎖住全表，這個時間會很長，這段時間業務不能訪問此表，影響很大。
• 大表會經常訪問與更新，就更有可能出現鎖等待。將資料切分，用空間換時間，變相降低訪問壓力

隨著業務發展，需要對某些欄位垂直拆分

資料量快速增長

安全性和可用性

參考部落格

[資料庫分庫分表思路](https://www.cnblogs.com/butterfly100/p/9034281.html)