分庫分表的21條法則速來碼住（上）

（一）好好的系統(tǒng)，為什么要分庫分表？

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

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

數(shù)據(jù)分片

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

數(shù)據(jù)節(jié)點

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

邏輯表

邏輯表是指具有相同結(jié)構(gòu)的水平拆分表的邏輯名稱。

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

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

業(yè)務(wù)邏輯SQL

select * from t_order where order_no='A11111'

真實執(zhí)行SQL

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

真實表

真實表就是在數(shù)據(jù)庫中真實存在的物理表DB_1.t_order_n。

廣播表

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

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

廣播表的特點 ：

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

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

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

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

單表

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

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

分片鍵

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

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

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

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

不僅如此 ShardingSphere 還支持根據(jù)多個字段作為分片健進行分片，這個在后續(xù)對應(yīng)章節(jié)中會詳細講。

分片策略

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

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

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

分片算法

分片算法則是用于對分片鍵進行運算，將數(shù)據(jù)劃分到具體的數(shù)據(jù)節(jié)點中。

常用的分片算法有很多：

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

實際業(yè)務(wù)開發(fā)中分片的邏輯要復(fù)雜的多，不同的算法適用于不同的場景和需求，需要根據(jù)實際情況進行選擇和調(diào)整。

綁定表

綁定表是那些具有相同分片規(guī)則的一組分片表，由于分片規(guī)則一致所產(chǎn)生的的數(shù)據(jù)落地位置相同，在JOIN聯(lián)合查詢時能有效避免跨庫操作。

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

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

當(dāng)使用 t_order 和 t_order_item 表進行多表聯(lián)合查詢，執(zhí)行如下聯(lián)合查詢的邏輯SQL。

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

如果不配置綁定表關(guān)系，兩個表的數(shù)據(jù)位置不確定就會全庫表查詢，出現(xiàn)笛卡爾積關(guān)聯(lián)查詢，將產(chǎn)生如下四條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

而配置綁定表關(guān)系后再進行關(guān)聯(lián)查詢時，分片規(guī)則一致產(chǎn)生的數(shù)據(jù)就會落到同一個庫表中，那么只需在當(dāng)前庫中 t_order_n 和 t_order_item_n 表關(guān)聯(liá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

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