SQL 解析

分庫分表后在應用層面執行一條 SQL 語句時，通常需要經過以下六個步驟：SQL 解析 -> 執?器優化 -> SQL 路由 -> SQL 改寫 -> SQL 執? -> 結果歸并 。

在這里插入圖片描述

SQL解析過程分為詞法解析和語法解析兩步，比如下邊查詢用戶訂單的SQL，先用詞法解析將這條SQL拆解成不可再分的原子單元。在根據不同數據庫方言所提供的字典，將這些單元歸類為關鍵字，表達式，變量或者操作符等類型。

SELECT order_no FROM t_order where  order_status > 0  and user_id = 10086

接著語法解析會將拆分后的SQL關鍵字轉換為抽象語法樹，通過對抽象語法樹遍歷，提煉出分片所需的上下文，上下文包含查詢字段信息（Field）、表信息（Table）、查詢條件（Condition）、排序信息（Order By）、分組信息（Group By）以及分頁信息（Limit）等，并標記出 SQL中有可能需要改寫的位置。

抽象語法樹

執?器優化

執?器優化是根據SQL查詢特點和執行統計信息，選擇最優的查詢計劃并執行，比如user_id字段有索引，那么會調整兩個查詢條件的位置，主要是提高SQL的執行效率。

SELECT order_no FROM t_order where user_id = 10086 and order_status > 0

SQL 路由

通過上邊的SQL解析得到了分片上下文數據，在匹配用戶配置的分片策略和算法，就可以運算生成路由路徑，將 SQL 語句路由到相應的數據節點上。

簡單點理解就是拿到分片策略中配置的分片鍵等信息，在從SQL解析結果中找到對應分片鍵字段的值，計算出 SQL該在哪個庫的哪個表中執行，SQL路由又根據有無分片健分為 分片路由 和 廣播路由。

有分?鍵的路由叫分片路由，細分為直接路由、標準路由和笛卡爾積路由這3種類型。

標準路由

標準路由是最推薦也是最為常?的分??式，它的適?范圍是不包含關聯查詢或僅包含綁定表之間關聯查詢的SQL。

當 SQL分片健的運算符為 = 時，路由結果將落?單庫（表），當分?運算符是BETWEEN 或IN 等范圍時，路由結果則不?定落?唯?的庫（表），因此?條邏輯SQL最終可能被拆分為多條?于執?的真實SQL。

SELECT * FROM t_order  where t_order_id in (1,2)

SQL路由處理后

SELECT * FROM t_order_0  where t_order_id in (1,2)
SELECT * FROM t_order_1  where t_order_id in (1,2)

直接路由

直接路由是直接將SQL路由到指定?庫、表的一種分?方式，而且直接路由可以?于分?鍵不在SQL中的場景，還可以執?包括?查詢、?定義函數等復雜情況的任意SQL。

笛卡爾積路由

笛卡爾路由是由?綁定表之間的關聯查詢產生的，比如訂單表t_order 分片鍵是t_order_id和用戶表t_user分片鍵是t_order_id，兩個表的分片鍵不同，要做聯表查詢，會執行笛卡爾積路由，查詢性能較低盡量避免走此路由模式。

SELECT * FROM t_order_0 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_0 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1

無分?鍵的路由又叫做廣播路由，可以劃分為全庫表路由、全庫路由、 全實例路由、單播路由和阻斷路由這 5種類型。

全庫表路由

全庫表路由針對的是數據庫 DQL和 DML，以及 DDL等操作，當我們執行一條邏輯表 t_order SQL時，在所有分片庫中對應的真實表 t_order_0 ··· t_order_n 內逐一執行。

全庫路由

全庫路由主要是對數據庫層面的操作，比如數據庫 SET 類型的數據庫管理命令，以及 TCL 這樣的事務控制語句。

對邏輯庫設置 autocommit 屬性后，所有對應的真實庫中都執行該命令。

SET autocommit=0;

全實例路由

全實例路由是針對數據庫實例的 DCL 操作（設置或更改數據庫用戶或角色權限），比如：創建一個用戶 order ，這個命令將在所有的真實庫實例中執行，以此確保 order 用戶可以正常訪問每一個數據庫實例。

CREATE USER order@127.0.0.1 identified BY '程序員小富';

單播路由

單播路由用來獲取某一真實表信息，比如獲得表的描述信息：

DESCRIBE t_order;

t_order 的真實表是 t_order_0 ···· t_order_n，他們的描述結構相完全同，我們只需在任意的真實表執行一次就可以。

阻斷路由

?來屏蔽SQL對數據庫的操作，例如：

USE order_db;

這個命令不會在真實數據庫中執?，因為 ShardingSphere 采?的是邏輯 Schema（數據庫的組織和結構） ?式，所以無需將切換數據庫的命令發送?真實數據庫中。

SQL 改寫

SQL經過解析、優化、路由后已經明確分片具體的落地執行的位置，接著就要將基于邏輯表開發的SQL改寫成可以在真實數據庫中可以正確執行的語句。比如查詢 t_order 訂單表，我們實際開發中 SQL是按邏輯表 t_order 寫的。

SELECT * FROM t_order

這時需要將分表配置中的邏輯表名稱改寫為路由之后所獲取的真實表名稱。

SELECT * FROM t_order_n

SQL執?

將路由和改寫后的真實 SQL 安全且高效發送到底層數據源執行。但這個過程并不能將 SQL 一股腦的通過 JDBC 直接發送至數據源執行，需平衡數據源連接創建以及內存占用所產生的消耗，它會自動化的平衡資源控制與執行效率。

結果歸并

將從各個數據節點獲取的多數據結果集，合并成一個大的結果集并正確的返回至請求客戶端，稱為結果歸并。而我們SQL中的排序、分組、分頁和聚合等語法，均是在歸并后的結果集上進行操作的。

分布式主鍵

數據分?后，一個邏輯表（t_order）對應諸多的真實表（t_order_n），它們之間由于?法互相感知，主鍵ID都從初始值累加，所以必然會產?重復主鍵ID，此時主鍵不再唯一那么對于業務來說也就沒意義了。

盡管可通過設置表?增主鍵 初始值 和 步? 的?式避免ID碰撞，但這樣會使維護成本加大，可擴展性差。

這個時候就需要我們手動為一條數據記錄，分配一個全局唯一的ID，這個ID被叫做分布式ID，而生產這個ID的系統通常被叫做發號器。

大家可以參考我之前發布的這篇文章 9種分布式ID生成方案

數據脫敏

分庫分表數據脫敏是一種有效的數據保護措施，可以確保敏感數據的機密性和安全性，減少數據泄露的風險。

比如，我們在分庫分表時可以指定表的哪些字段為脫敏列，并設置對應的脫敏算法，在數據分片時解析到執行SQL中有待脫敏字段，會直接將字段值脫敏后的寫入庫表內。

對于用戶的個人信息，如姓名、地址和電話號碼等，可以通過加密、隨機化或替換成偽隨機數據的方式進行脫敏，以確保用戶的隱私得到保護。

大家可以參考我之前發布的這篇文章 大廠也在用的 6種 數據脫敏方案

分布式事務

分布式事務的核心問題是如何實現跨多個數據源的原子性操作。

由于不同的服務通常會使用不同的數據源來存儲和管理數據，因此，跨數據源的操作可能會導致數據不一致性或丟失的風險。因此，保證分布式事務的一致性是非常重要的。

以訂單系統為例，它需要調用支付系統、庫存系統、積分系統等多個系統，而每個系統都維護自己的數據庫實例，系統間通過API接口交換數據。

為了保證下單后多個系統同時調用成功，可以使用強一致性事務的XA協議，或者柔性事務的代表工具Seata，來實現分布式事務的一致性。這些工具可以幫助開發人員簡化分布式事務的實現，減少錯誤和漏洞的出現，提高系統的穩定性和可靠性。

經過分庫分表之后，問題的難度進一步提升。自身訂單服務，也需要處理跨數據源的操作。這樣一來，系統的復雜度顯著增加。因此，不到萬不得已的情況下，最好避免采用分庫分表的解決方案。

關于分布式事務詳細的介紹，大家可以參考我之前發布的這篇文章 對比 5 種分布式事務方案，還是寵幸了阿里的 Seata（原理 + 實戰）

數據遷移

分庫分表后還有個讓人頭疼的問題，那就是數據遷移，為了不影響現有的業務系統，通常會新建數據庫集群遷移數據。將數據從舊集群的數據庫、表遷移到新集群的分庫、分表中。這是一個比較復雜的過程，在遷移過程中需要考慮數據量、數據一致性、遷移速度等諸多因素。

遷移主要針對 存量數據 和 增量數據 的處理，存量數據指舊數據源中已經存在且有價值的歷史數據，增量數據指當下持續增長以及未來產生的業務數據。

存量數據可以采用定時、分批次的遷移，遷移過程可能會持續幾天。

增量數據可以采用新、舊數據庫集群雙寫模式。待數據遷移完畢，業務驗證了數據一致性，應用直接切換數據源即可。

后續我們會結合三方工具，來演示遷移的過程。

影子庫

什么是影子庫（Shadow Table）？

影子庫是一個與生產環境數據庫結構完全相同的實例，它存在的意義是為了在不影響線上系統的情況下，驗證數據庫遷移或者其他數據庫變更操作的正確性，以及全鏈路壓測。影子庫中存儲的數據是從生產環境中定期復制過來的，但是它不對線上業務產生任何影響，僅用于測試，驗證和調試。

在進行數據庫升級、版本變更、參數調優等操作前，通過在影子庫上模擬這些操作，可以發現潛在的問題，因為測試環境的數據是不可靠的。

在使用影子庫時，需要遵循以下幾個原則：

• 與生產環境數據庫的結構應該完全一致，包括表結構、索引、約束等；
• 數據要與生產環境保持一致，可以通過定期同步方式實現；
• 讀寫操作不會影響生產環境，一般情況下應該禁止在影子庫上執行更新、刪除等操作；
• 由于影子庫的數據特點，訪問權限應該嚴格控制，只允許授權人員進行訪問和操作；

總結

本文介紹了關于分庫分表架構的21個通用概念，有一定的了解之后，接下來我們將進入更深度的內容，包括讀寫分離、數據脫敏、分布式主鍵、分布式事務、配置中心、注冊中心、Proxy服務等實戰案例的講解和源碼分析。