| 策略 | 分片鍵 | 路由邏輯 | 優點 | 缺點 |
| 範圍分片 | Id 範圍、日期範圍 | 查表/函數映射 | 範圍查詢高效、易擴容 | 熱點傾斜 (新範圍寫入集中) |
| 雜湊分片 | UserId % N、Hash(租戶Id) | 模數/一致性雜湊 | 負載均勻、無熱點 | 跨分片查詢需散播聚合、擴容需重雜湊 |
| 目錄分片 | 租戶Id、區域代碼 | 查閱表 (Shard Map) | 業務語意清晰、隔離性強 | 目錄服務成單點、大租戶傾斜 |
分布式分區檢視表 — SQL Server 原生聯合查詢
-- 各分片建立相同結構表 + CHECK 約束
CREATE TABLE Orders_2023_Q1 (OrderID INT, OrderDate DATE CHECK (OrderDate BETWEEN '2023-01-01' AND '2023-03-31'), ...);
CREATE TABLE Orders_2023_Q2 (OrderID INT, OrderDate DATE CHECK (OrderDate BETWEEN '2023-04-01' AND '2023-06-30'), ...);
-- 建立檢視表
CREATE VIEW dbo.Orders_All AS
SELECT * FROM Server1.DB.dbo.Orders_2023_Q1
UNION ALL SELECT * FROM Server2.DB.dbo.Orders_2023_Q2
UNION ALL ...;
- 優化器利用 CHECK 約束 自動消除無關分片 (Partition Elimination)
- 支援 UPDATE/INSERT (需符合 CHECK 約束)
- 限制:所有分片結構嚴格一致、統計資訊需手動同步、跨伺服器需連結伺服器 (延遲高)
路徑四:第三方中間件 / NewSQL
- Proxy 層路由: ProxySQL、MaxScale、Vitess (MySQL 生態)、ShardingSphere (Java 生態)
- NewSQL 分散式資料庫: TiDB、CockroachDB、YugabyteDB、OceanBase — 兼容 MySQL/PostgreSQL 協議,強一致性分散式交易、自動分片重平衡
- SQL Server 生態較弱: 缺乏成熟開源 Proxy,通常走應用層 Sharding Library 或遷移至 NewSQL
架構選型決策樹
- 資料量 < 10TB、核心交易、強一致性、團隊小 → Scale-Up + 讀取複本/AG 次要複本
- 需最小化改造、預算彈性、雲優先 → Azure SQL 超大規模 / SQL MI
- 地理分散、唯讀為主、可容忍秒級延遲 → 交易式複寫 / AG 可讀次要
- 多租戶 SaaS、寫入高併發、可接受應用層路由改造 → 水平分片 (雜湊/目錄) + Shard Map Manager
- 追求開源、無廠商鎖定、團隊有分散式能力 → TiDB / CockroachDB 遷移
遷移策略建議
- 雙寫驗證: 新舊系統並行寫入,比對資料一致性
- 流量漸進切換: 讀流量先切 (可回滾),再切寫流量
- 資料同步工具: Azure DMS、Attunity、自建 CDC + Kafka
- 保留回滾窗口: 至少 2 週雙寫並行,確認零業務影響再下線舊系統
Scale-Out 沒有銀彈,只有權衡。先優化單機 (索引、查詢、記憶體、壓縮)、再讀寫分離 (AG/複寫)、最後才考慮分片/遷移 NewSQL,是風險最低、ROI 最高的演進路徑。
- 上一篇文章: SQL Server I/O 瓶頸識別與磁碟子系統最佳實務:效能計數器、DMV、碎片整理與 RAID 規劃
- 下一篇文章: SQL Server 查詢結果匯出 Excel 完整指南:SSMS 精靈、BCP、OPENROWSET、CLR 与自動化存儲過程
Copyright ©
程式碼之家 All Rights Reserved