垂直分庫分表（Vertical Sharding） 和 水平分庫分表（Horizontal Sharding） 是數據庫拆分的兩種策略。它們在大規模數據庫優化、分布式架構設計中至關重要，主要用于 降低單庫壓力、提高查詢效率、支持高并發。

---

1. 垂直分庫分表（Vertical Sharding）

概念

垂直分庫 和 垂直分表 的核心思想是按業務模塊或功能拆分數據庫，即：

• 垂直分庫（Vertical Database Partitioning）：將不同的業務模塊拆分到不同的數據庫中
• 垂直分表（Vertical Table Partitioning）：在同一個數據庫中，將一個大表按字段拆分成多個表

示例

假設有一個 電商系統，包含 用戶信息、訂單、商品、支付 等功能，如果所有數據都存放在一個數據庫 ecommerce_db，會導致：

• 單庫壓力過大
• 查詢、寫入效率下降
• 影響數據庫擴展能力

可以采用 垂直分庫：

user_db         → 存儲用戶信息
order_db        → 存儲訂單信息
product_db      → 存儲商品信息
payment_db      → 存儲支付信息

不同的業務數據存儲在不同的數據庫中，每個數據庫只處理自己相關的業務，提高效率。

---

垂直分庫 vs. 垂直分表

方式	說明	適用場景
垂直分庫	按業務模塊拆分數據庫，每個庫獨立存儲不同業務數據	業務數據相對獨立，不同模塊間交互少
垂直分表	在同一個數據庫內，將大表按字段拆分成多個小表	單表字段過多，部分字段訪問頻率低

查詢示例

查詢用戶信息：

SELECT * FROM user_db.users WHERE id = 1001;

查詢訂單信息：

SELECT * FROM order_db.orders WHERE user_id = 1001;

各個數據庫可以獨立擴展，互不影響。

---

優點

? 分擔數據庫壓力：不同業務拆分到不同數據庫，查詢、寫入性能提升
? 不同數據庫可獨立優化：如 user_db 讀多寫少，可優化為讀寫分離；order_db 寫入頻繁，可優化為高性能寫庫
? 支持不同存儲策略：如 user_db 存 MySQL，payment_db 存 PostgreSQL

缺點

? 跨庫 JOIN 復雜：無法直接執行 JOIN 查詢，需要在應用層處理
? 事務一致性問題：跨庫事務需要分布式事務（如 TCC、XA）
? 運維復雜：多個數據庫管理、備份、遷移成本增加

---

2. 水平分庫分表（Horizontal Sharding）

概念

水平分庫分表 的核心思想是按照數據量進行拆分，即：

• 水平分庫（Horizontal Database Partitioning）：將數據按某個分片鍵（Sharding Key） 均勻分布到多個數據庫
• 水平分表（Horizontal Table Partitioning）：將數據按分片鍵分布到多個相同結構的表

---

示例

假設有一個 orders 表，存儲1 億條訂單數據，直接查詢會導致：

• 查詢速度變慢
• 索引過大，影響性能
• 數據庫寫入壓力過大

水平分庫

可以按照 user_id % 4 進行分庫：

order_db_0: user_id % 4 = 0
order_db_1: user_id % 4 = 1
order_db_2: user_id % 4 = 2
order_db_3: user_id % 4 = 3

查詢用戶訂單：

SELECT * FROM order_db_2.orders WHERE user_id = 1002;

數據分布均勻，每個庫的壓力降低。

水平分表

在 order_db 內部，將 orders 表按 user_id % 10 拆分為 10 張表：

orders_0: user_id % 10 = 0
orders_1: user_id % 10 = 1
...
orders_9: user_id % 10 = 9

查詢用戶訂單：

SELECT * FROM orders_2 WHERE user_id = 1002;

避免單表數據過大，提高查詢速度。

---

水平分庫 vs. 水平分表

方式	說明	適用場景
水平分庫	按 Sharding Key 進行數據庫拆分，不同數據庫存儲相同結構的數據	單庫容量受限，分片鍵可均勻分布數據
水平分表	在同一個數據庫內，將大表拆分為多個小表	單表數據量過大，查詢變慢，索引維護困難

---

優點

? 單庫壓力減少：數據分布在多個數據庫或表，查詢、寫入速度更快
? 讀寫性能提升：不同庫可并行查詢、寫入，提高吞吐量
? 易于擴展：可以繼續增加數據庫或表，支持大規模數據存儲

缺點

? 跨庫查詢復雜：需要 UNION ALL 或應用層合并
? 事務管理難度大：需要分布式事務，如 TCC、XA
? 數據路由管理：需要在應用層或 Sharding Proxy 進行數據分片管理

---

3. 垂直分庫分表 vs. 水平分庫分表

對比項	垂直分庫分表	水平分庫分表
拆分方式	按業務模塊拆分	按數據量拆分
數據存儲	每個庫存儲不同表	每個庫存儲相同表，但數據不同
適用場景	業務數據獨立，如用戶、訂單、支付分開	單表數據過大，查詢和寫入性能受限
查詢優化	業務查詢獨立，無需跨庫查詢	需要跨庫合并查詢
事務管理	業務間事務較少	可能涉及跨庫事務，需分布式事務
運維難度	需要管理多個數據庫	需要管理數據路由、分片規則
擴展性	適合業務擴展，但數據量不均衡	可水平擴展，適合大數據量場景

---

4. 結合使用

在 大規模系統 中，通常會 結合垂直分庫+水平分庫 進行優化。

示例：電商平臺

1. 按業務拆分（垂直分庫）

   • user_db（用戶數據）
   • order_db（訂單數據）
   • payment_db（支付數據）

2. 按數據量拆分（水平分庫）

   • order_db_0, order_db_1, order_db_2...

3. 按查詢優化（垂直分表）

   • users_basic, users_detail

這樣既能保證業務獨立性，又能提升查詢和寫入性能，適用于大規模系統架構。

---

總結

• 垂直分庫分表 適用于 不同業務模塊獨立存儲，減少數據庫負載
• 水平分庫分表 適用于 大數據量、高并發系統，提高查詢和寫入性能
• 大規模系統通常結合使用，即 先垂直拆分業務，再水平拆分數據

如果你有具體的業務場景，可以告訴我，我可以給你更詳細的架構設計建議！🚀