（一）好好的系統，為什么要分庫分表？

還是不著急實戰，咱們先介紹下在分庫分表架構實施過程中，會接觸到的一些通用概念，了解這些概念能夠幫助理解市面上其他的分庫分表工具，盡管它們的實現方法可能存在差異，但整體思路基本一致。因此，在開始實際操作之前，我們有必要先掌握這些通用概念，以便更好地理解和應用分庫分表技術。

我們結合具體業務場景，以t_order表為例進行架構優化。由于數據量已經達到億級別，查詢性能嚴重下降，因此我們采用了分庫分表技術來處理這個問題。具體而言，我們將原本的單庫分成了兩個庫，分別為DB_1和DB_2，并在每個庫中再次進行分表處理，生成t_order_1和t_order_2兩張表，實現對訂單表的分庫分表處理。

數據分片

通常我們在提到分庫分表的時候，大多是以水平切分模式（水平分庫、分表）為基礎來說的，數據分片它將原本一張數據量較大的表 t_order 拆分生成數個表結構完全一致的小數據量表（拆分表） t_order_0、t_order_1、···、t_order_n，每張表只存儲原大表中的一部分數據。

數據節點

數據節點是數據分片中一個不可再分的最小單元（表），它由數據源名稱和數據表組成，例如上圖中 DB_1.t_order_1、DB_2.t_order_2 就表示一個數據節點。

邏輯表

邏輯表是指具有相同結構的水平拆分表的邏輯名稱。

比如我們將訂單表t_order 分表拆分成 t_order_0 ··· t_order_9等10張表，這時我們的數據庫中已經不存在 t_order這張表，取而代之的是若干的t_order_n表。

分庫分表通常對業務代碼都是無侵入式的，開發者只專注于業務邏輯SQL編碼，我們在代碼中SQL依然按 t_order來寫，而在執行邏輯SQL前將其解析成對應的數據庫真實執行的SQL。此時 t_order 就是這些拆分表的邏輯表。

業務邏輯SQL

select * from t_order where order_no='A11111'

真實執行SQL

select * from DB_1.t_order_n where order_no='A11111'

真實表

真實表就是在數據庫中真實存在的物理表DB_1.t_order_n。

廣播表

廣播表是一類特殊的表，其表結構和數據在所有分片數據源中均完全一致。與拆分表相比，廣播表的數據量較小、更新頻率較低，通常用于字典表或配置表等場景。由于其在所有節點上都有副本，因此可以大大降低JOIN關聯查詢的網絡開銷，提高查詢效率。

需要注意的是，對于廣播表的修改操作需要保證同步性，以確保所有節點上的數據保持一致。

廣播表的特點 ：

• 在所有分片數據源中，廣播表的數據完全一致。因此，對廣播表的操作（如插入、更新和刪除）會實時在每個分片數據源中執行一遍，以保證數據的一致性。
• 對于廣播表的查詢操作，僅需要在任意一個分片數據源中執行一次即可。
• 與任何其他表進行JOIN操作都是可行的，因為由于廣播表的數據在所有節點上均一致，所以可以訪問到任何一個節點上的相同數據。

什么樣的表可以作為廣播表呢？

訂單管理系統中，往往需要查詢統計某個城市地區的訂單數據，這就會涉及到省份地區表t_city與訂單流水表DB_n.t_order_n進行JOIN查詢，因此可以考慮將省份地區表設計為廣播表，核心理念就是 避免跨庫JOIN操作 。

注意 ：上邊我們提到廣播表在數據插入、更新與刪除會實時在每個分片數據源均執行，也就是說如果你有1000個分片數據源，那么修改一次廣播表就要執行1000次SQL，所以盡量不在并發環境下和業務高峰時進行，以免影響系統的性能。

單表

單表指所有的分片數據源中僅唯一存在的表（沒有分片的表），適用于數據量不大且無需分片的表。

如果一張表的數據量預估在千萬級別，且沒有與其他拆分表進行關聯查詢的需求，建議將其設置為單表類型，存儲在默認分片數據源中。

分片鍵

分片鍵決定了數據落地的位置，也就是數據將會被分配到哪個數據節點上存儲。因此，分片鍵的選擇非常重要。

比如我們將 t_order 表進行分片后，當插入一條訂單數據執行SQL時，需要通過解析SQL語句中指定的分片鍵來計算數據應該落在哪個分片中。以表中order_no字段為例，我們可以通過對其取模運算（比如 order_no % 2）來得到分片編號，然后根據分片編號分配數據到對應的數據庫實例（比如 DB_1 和 DB_2）。拆分表也是同理計算。

在這個過程中，order_no 就是 t_order 表的分片鍵。也就是說，每一條訂單數據的 order_no 值決定了它應該存放的數據庫實例和表。選擇一個適合作為分片鍵的字段可以更好地利用水平分片帶來的性能提升。

這樣同一個訂單的相關數據就會落在同一個數據庫、表中，查詢訂單時同理計算，就可直接定位數據位置，大幅提升數據檢索的性能，避免了全庫表掃描。

不僅如此 ShardingSphere 還支持根據多個字段作為分片健進行分片，這個在后續對應章節中會詳細講。

分片策略

分片策略來指定使用哪種分片算法、選擇哪個字段作為分片鍵以及如何將數據分配到不同的節點上。

分片策略是由分片算法和分片健組合而成，分片策略中可以使用多種分片算法和對多個分片鍵進行運算。

分庫、分表的分片策略配置是相對獨立的，可以各自使用不同的策略與算法，每種策略中可以是多個分片算法的組合，每個分片算法可以對多個分片健做邏輯判斷。

分片算法

分片算法則是用于對分片鍵進行運算，將數據劃分到具體的數據節點中。

常用的分片算法有很多：

• 哈希分片 ：根據分片鍵的哈希值來決定數據應該落到哪個節點上。例如，根據用戶 ID 進行哈希分片，將屬于同一個用戶的數據分配到同一個節點上，便于后續的查詢操作。
• 范圍分片 ：分片鍵值按區間范圍分配到不同的節點上。例如，根據訂單創建時間或者地理位置來進行分片。
• 取模分片 ：將分片鍵值對分片數取模，將結果作為數據應該分配到的節點編號。例如， order_no % 2 將訂單數據分到兩個節點之一。
• .....

實際業務開發中分片的邏輯要復雜的多，不同的算法適用于不同的場景和需求，需要根據實際情況進行選擇和調整。

綁定表

綁定表是那些具有相同分片規則的一組分片表，由于分片規則一致所產生的的數據落地位置相同，在JOIN聯合查詢時能有效避免跨庫操作。

比如：t_order 訂單表和 t_order_item 訂單項目表，都以 order_no 字段作為分片鍵，并且使用 order_no 進行關聯，因此兩張表互為綁定表關系。

使用綁定表進行多表關聯查詢時，必須使用分片鍵進行關聯，否則會出現笛卡爾積關聯或跨庫關聯，從而影響查詢效率。

當使用 t_order 和 t_order_item 表進行多表聯合查詢，執行如下聯合查詢的邏輯SQL。

SELECT * FROM t_order o JOIN t_order_item i ON o.order_no=i.order_no

如果不配置綁定表關系，兩個表的數據位置不確定就會全庫表查詢，出現笛卡爾積關聯查詢，將產生如下四條SQL。

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_no=i.order_no 
SELECT * FROM t_order_0 o JOIN t_order_item_1 i ON o.order_no=i.order_no 
SELECT * FROM t_order_1 o JOIN t_order_item_0 i ON o.order_no=i.order_no 
SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_no=i.order_no

而配置綁定表關系后再進行關聯查詢時，分片規則一致產生的數據就會落到同一個庫表中，那么只需在當前庫中 t_order_n 和 t_order_item_n 表關聯即可。

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id 
SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id

注意 ：在關聯查詢時 t_order 它作為整個聯合查詢的主表。所有相關的路由計算都只使用主表的策略，t_order_item 表的分片相關的計算也會使用 t_order 的條件，所以要保證綁定表之間的分片鍵要完全相同。