1. 為什么要分庫分表？

1.1 單庫瓶頸表現

• 存儲瓶頸：單表數據超過5000萬行，查詢性能急劇下降
• 性能瓶頸：單庫QPS超過5000后響應延遲顯著增加
• 可用性風險：單點故障導致全系統不可用

1.2 突破性優勢

+----------------+--------------+-----------------+
| 指標           | 單庫單表      | 分庫分表(16分片) |
+----------------+--------------+-----------------+
| 寫入吞吐量      | 2000 TPS     | 32000 TPS       |
| 查詢延遲        | 120ms        | 15ms            |
| 數據容量        | 500GB        | 8TB             |
+----------------+--------------+-----------------+

2. 分片策略深度解析

2.1 水平分片 vs 垂直分片

2.2 典型分片算法對比

算法	適用場景	優點	缺點
哈希取模	均勻分布場景	數據分布均勻	擴容困難
一致性哈希	需要動態擴容	擴容影響小	實現復雜
范圍分片	時序數據	支持范圍查詢	容易產生熱點
基因分片	關聯查詢優化	支持跨表關聯	設計復雜

3. 生產環境實施流程

3.1 分片方案設計

// 基因分片算法示例
public class GeneSharding {public static String getShard(String orderId) {// 提取用戶ID后四位作為基因String gene = orderId.substring(orderId.length()-4);int hash = Math.abs(gene.hashCode()) % 16;return "shard_" + hash;}
}

3.2 數據遷移方案

1. 全量遷移：使用DataX工具導出歷史數據
2. 增量同步：通過Canal監聽binlog
3. 數據校驗：對比MD5校驗和
4. 流量切換：灰度切換讀/寫流量

3.3 應用改造要點

<!-- MyBatis分表配置示例 -->
<insert id="insertOrder"><!-- 自動路由到對應分表 -->INSERT INTO order_${shardIndex} VALUES (#{orderId}, #{amount})
</insert>

4. 分庫分表中間件選型

4.1 主流方案對比

工具	接入方式	功能完整性	學習成本	社區支持
ShardingSphere	JDBC代理	★★★★★	★★☆	★★★★★
MyCat	數據庫代理	★★★★☆	★★★	★★★☆
Vitess	gRPC接口	★★★★☆	★★★★	★★★★

4.2 ShardingSphere配置示例

application-sharding.yml
spring:shardingsphere:rules:sharding:tables:t_order:actual-data-nodes: ds${0..1}.t_order_${0..7}database-strategy:standard:sharding-column: user_idsharding-algorithm-name: db_hashtable-strategy:standard:sharding-column: order_timesharding-algorithm-name: table_range

5. 常見問題解決方案

5.1 分布式事務處理

// Seata分布式事務示例
@GlobalTransactional
public void createOrder(Order order) {orderDao.insert(order);          // 寫訂單庫inventoryDao.deduct(order);      // 寫庫存庫accountDao.updateBalance(order); // 寫賬戶庫
}

5.2 跨分片查詢優化

-- 使用全局索引表
CREATE TABLE global_index (biz_id VARCHAR(32) PRIMARY KEY,shard_key VARCHAR(32) NOT NULL
);-- 查詢時先查索引表
SELECT shard_key FROM global_index WHERE biz_id = 'ORDER_123';
SELECT * FROM t_order_${shard_key} WHERE order_id = 'ORDER_123';

6. 監控與調優

6.1 關鍵監控指標

指標類別	監控項	報警閾值
資源使用	分片存儲空間使用率	>80%
性能指標	跨分片查詢比例	>5%
業務指標	分片數據分布偏差率	>15%

6.2 性能調優技巧

1. 熱點分片處理：動態調整路由策略
2. 查詢優化：強制指定分片鍵
3. 緩存加速：二級緩存+布隆過濾器
4. 連接管理：合理配置連接池參數

7. 真實案例：電商平臺改造

7.1 改造前架構

           [應用集群]|[MySQL主從]500GB數據3000 TPS

7.2 分庫分表方案

16個分庫（用戶ID哈希）
每個庫包含：8個訂單表（時間范圍分片）4個支付表（訂單ID基因分片）

7.3 改造成效

峰值處理能力：52000 TPS → 提升17倍
平均查詢延遲：86ms → 9ms
年度存儲成本：降低42%

8. 演進路線建議

timeline階段1 : 單庫讀寫分離階段2 : 垂直分庫（業務拆分）階段3 : 水平分表（單業務分表）階段4 : 多維度分庫分表階段5 : 單元化架構

技術選型建議：
? 數據量<1TB：使用中間件方案

? 數據量>1TB：考慮NewSQL數據庫（TiDB/CockroachDB）

? 超高并發場景：結合內存數據庫（Redis/Aerospike）

通過合理的分庫分表策略，可以使傳統關系型數據庫支撐起海量數據場景。關鍵在于根據業務特征選擇合適的分片策略，并建立完善的監控運維體系。