我們一起聊聊分庫分表帶來了哪些問題？
作者：蘇三
分庫分表是解決單庫單表性能瓶頸的有效手段，但也會引入新的復雜性和技術挑戰。這篇文章跟大家一起聊聊，分庫分表后帶來的7個問題，以及相關的解決方案，希望對你會有所幫助。
1. 全局唯一 ID 問題
問題描述
在分庫分表后，每張表的自增 ID 只在本表范圍內唯一，但無法保證全局唯一。
例如：
- 訂單表_1 的主鍵從 1 開始，訂單表_2 的主鍵也從 1 開始。
- 在需要全局唯一 ID 的場景（如訂單號、用戶 ID）中會發生沖突。
解決方案
1.1 使用分布式 ID 生成器
推薦工具：
- Snowflake：Twitter 開源的分布式 ID 算法。
- 百度 UidGenerator：基于 Snowflake 的改進版。
- Leaf：美團開源，號段模式和 Snowflake 雙支持。
代碼示例：Snowflake 算法
public class SnowflakeIdGenerator {
private final long epoch = 1622476800000L; // 自定義時間戳
private final long workerIdBits = 5L; // 機器ID
private final long datacenterIdBits = 5L; // 數據中心ID
private final long sequenceBits = 12L; // 序列號
private final long maxWorkerId = ~(-1L << workerIdBits);
private final long maxDatacenterId = ~(-1L << datacenterIdBits);
private final long sequenceMask = ~(-1L << sequenceBits);
private long workerId;
private long datacenterId;
private long sequence = 0L;
private long lastTimestamp = -1L;
public SnowflakeIdGenerator(long workerId, long datacenterId) {
if (workerId > maxWorkerId || workerId < 0) throw new IllegalArgumentException("Worker ID out of range");
if (datacenterId > maxDatacenterId || datacenterId < 0) throw new IllegalArgumentException("Datacenter ID out of range");
this.workerId = workerId;
this.datacenterId = datacenterId;
}
public synchronized long nextId() {
long timestamp = System.currentTimeMillis();
if (timestamp < lastTimestamp) throw new RuntimeException("Clock moved backwards");
if (timestamp == lastTimestamp) {
sequence = (sequence + 1) & sequenceMask;
if (sequence == 0) timestamp = waitNextMillis(lastTimestamp);
} else sequence = 0L;
lastTimestamp = timestamp;
return ((timestamp - epoch) << (workerIdBits + datacenterIdBits + sequenceBits))
| (datacenterId << (workerIdBits + sequenceBits))
| (workerId << sequenceBits)
| sequence;
}
private long waitNextMillis(long lastTimestamp) {
long timestamp = System.currentTimeMillis();
while (timestamp <= lastTimestamp) timestamp = System.currentTimeMillis();
return timestamp;
}
}1.2 數據庫號段分配
- 原理：維護一個獨立的 global_id 表，分庫按步長分配 ID：
a.庫 1：ID 步長為 2，從 1 開始（1, 3, 5...）。
b.庫 2：ID 步長為 2，從 2 開始（2, 4, 6...）。
示例
CREATE TABLE global_id (
id INT PRIMARY KEY AUTO_INCREMENT,
stub CHAR(1) NOT NULL UNIQUE
);
-- 步長設置：
SET @@auto_increment_increment = 2;
SET @@auto_increment_offset = 1;2. 跨庫跨表查詢復雜性
問題描述
分庫分表后，聚合查詢（如總數統計、分頁查詢）需要跨多個分片表執行，增加了查詢復雜度。
例如：
- 查詢所有訂單總數，需要跨 10 個訂單表聚合。
- 按創建時間分頁查詢所有訂單。
解決方案
2.1 使用中間件（推薦）
- ShardingSphere 或 MyCAT：支持 SQL 分片執行和結果合并。
- 優點：業務代碼無需修改，中間件完成分庫分表邏輯。
2.2 手動分片查詢
- 按分片逐一查詢數據，在業務層合并結果。
示例代碼：聚合查詢
public int countAllOrders() {
int total = 0;
for (String db : List.of("db1", "db2", "db3")) {
String sql = "SELECT COUNT(*) FROM " + db + ".orders";
total += jdbcTemplate.queryForObject(sql, Integer.class);
}
return total;
}示例代碼：跨分片分頁查詢
public List<Order> paginateOrders(int page, int size) {
List<Order> allOrders = new ArrayList<>();
for (String table : List.of("orders_1", "orders_2")) {
String sql = "SELECT * FROM " + table + " LIMIT 100";
allOrders.addAll(jdbcTemplate.query(sql, new OrderRowMapper()));
}
allOrders.sort(Comparator.comparing(Order::getCreatedAt));
return allOrders.stream()
.skip((page - 1) * size)
.limit(size)
.collect(Collectors.toList());
}手動分片查詢的方案，如果數據比較多，性能會比較差。
3. 分布式事務問題
問題描述
分布式事務（如訂單表在庫 A，庫存表在庫 B）無法使用單庫事務，導致可能會出現數據的一致性問題。
解決方案
3.1 分布式事務框架
- Seata：支持跨庫的分布式事務。
- 示例代碼：
@GlobalTransactional
public void createOrder(Order order) {
orderService.saveOrder(order); // 寫入庫A
stockService.reduceStock(order.getProductId()); // 更新庫B
}3.2 柔性事務
- 使用消息中間件實現最終一致性。
- 典型實現：RocketMQ 消息事務。
4. 分片鍵設計問題
問題描述
分片鍵選擇不當可能導致數據傾斜（熱點問題）或查詢路由效率低。
解決方案
4.1 分片鍵設計原則
- 數據分布均勻：避免熱點問題。
- 常用查詢字段：盡量選高頻查詢字段。
4.2 路由表
- 維護全局路由表，映射分片鍵到分表。
示例代碼：路由表查詢
public String getTargetTable(int userId) {
String sql = "SELECT table_name FROM routing_table WHERE user_id = ?";
return jdbcTemplate.queryForObject(sql, new Object[]{userId}, String.class);
}5. 數據遷移問題
問題描述
擴容（如從 4 個分片擴展到 8 個分片）時，舊數據需要遷移到新分片，遷移復雜且可能影響線上服務。
解決方案
5.1 雙寫策略
- 數據遷移期間，舊表和新表同時寫入。
- 待遷移完成后，切換到新表。
5.2 增量同步
- 使用 Canal 監聽 MySQL Binlog，將數據遷移到新分片。
示例：Canal 配置
canal.destinations:
example:
mysql:
hostname: localhost
port: 3306
username: root
password: password
kafka:
servers: localhost:9092
topic: example_topic6. 分頁查詢問題
問題描述
分頁查詢需要從多個分片表合并數據，再統一分頁，邏輯復雜度增加。
解決方案
- 各分片分頁后合并：先按分片分頁查詢，業務層合并排序后分頁。
- 中間件支持分頁：如 ShardingSphere。
示例代碼：跨分片分頁
public List<Order> queryPagedOrders(int page, int size) {
List<Order> results = new ArrayList<>();
for (String table : List.of("orders_1", "orders_2")) {
results.addAll(jdbcTemplate.query("SELECT * FROM " + table + " LIMIT 100", new OrderRowMapper()));
}
results.sort(Comparator.comparing(Order::getCreatedAt));
return results.stream().skip((page - 1) * size).limit(size).collect(Collectors.toList());
}但如果分的表太多，可能會有內存占用過多的問題，需要做好控制。
7. 運維復雜性
問題描述
分庫分表后，運維難度增加：
- 數據庫實例多，監控和備份復雜。
- 故障排查需要跨多個庫。
解決方案
- 自動化運維平臺：如阿里云 DMS。
- 監控工具：使用 Prometheus + Grafana 實現分片監控。
總結
分庫分表本質上是“性能換復雜度”，它雖然能有效提升系統的性能和擴展性，但問題也隨之而來。
分庫分表后帶來的問題總結如下：
問題 | 解決方案 |
全局唯一 ID | 雪花算法、號段分配、Leaf |
跨庫跨表查詢 | 中間件支持（如 ShardingSphere）或手動合并 |
分布式事務 | 分布式事務框架（Seata）、消息最終一致性 |
分片鍵設計問題 | 路由表或高效分片鍵 |
數據遷移問題 | 雙寫策略或增量同步（如 Canal） |
分頁查詢問題 | 分片查詢后合并排序 |
運維復雜性 | 自動化工具（DMS）、監控工具（Prometheus + Grafana） |
應根據業務場景選擇適合的分庫分表策略，并通過工具和技術方案，解決由此帶來的一些問題，最終實現系統的高性能與高可靠性。
責任編輯：武曉燕
來源：
蘇三說技術
