我們一起聊聊分庫分表帶來了哪些問題？
作者：蘇三
分庫分表是解決單庫單表性能瓶頸的有效手段，但也會(huì)引入新的復(fù)雜性和技術(shù)挑戰(zhàn)。這篇文章跟大家一起聊聊，分庫分表后帶來的7個(gè)問題，以及相關(guān)的解決方案，希望對(duì)你會(huì)有所幫助。
1. 全局唯一 ID 問題
問題描述
在分庫分表后，每張表的自增 ID 只在本表范圍內(nèi)唯一，但無法保證全局唯一。
例如：
- 訂單表_1 的主鍵從 1 開始，訂單表_2 的主鍵也從 1 開始。
- 在需要全局唯一 ID 的場(chǎng)景（如訂單號(hào)、用戶 ID）中會(huì)發(fā)生沖突。
解決方案
1.1 使用分布式 ID 生成器
推薦工具：
- Snowflake：Twitter 開源的分布式 ID 算法。
- 百度 UidGenerator：基于 Snowflake 的改進(jìn)版。
- Leaf：美團(tuán)開源，號(hào)段模式和 Snowflake 雙支持。
代碼示例：Snowflake 算法
public class SnowflakeIdGenerator {
private final long epoch = 1622476800000L; // 自定義時(shí)間戳
private final long workerIdBits = 5L; // 機(jī)器ID
private final long datacenterIdBits = 5L; // 數(shù)據(jù)中心ID
private final long sequenceBits = 12L; // 序列號(hào)
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 數(shù)據(jù)庫號(hào)段分配
- 原理：維護(hù)一個(gè)獨(dú)立的 global_id 表，分庫按步長(zhǎng)分配 ID：
a.庫 1：ID 步長(zhǎng)為 2，從 1 開始（1, 3, 5...）。
b.庫 2：ID 步長(zhǎng)為 2，從 2 開始（2, 4, 6...）。
示例
CREATE TABLE global_id (
id INT PRIMARY KEY AUTO_INCREMENT,
stub CHAR(1) NOT NULL UNIQUE
);
-- 步長(zhǎng)設(shè)置：
SET @@auto_increment_increment = 2;
SET @@auto_increment_offset = 1;2. 跨庫跨表查詢復(fù)雜性
問題描述
分庫分表后，聚合查詢（如總數(shù)統(tǒng)計(jì)、分頁查詢）需要跨多個(gè)分片表執(zhí)行，增加了查詢復(fù)雜度。
例如：
- 查詢所有訂單總數(shù)，需要跨 10 個(gè)訂單表聚合。
- 按創(chuàng)建時(shí)間分頁查詢所有訂單。
解決方案
2.1 使用中間件（推薦）
- ShardingSphere 或 MyCAT：支持 SQL 分片執(zhí)行和結(jié)果合并。
- 優(yōu)點(diǎn)：業(yè)務(wù)代碼無需修改，中間件完成分庫分表邏輯。
2.2 手動(dòng)分片查詢
- 按分片逐一查詢數(shù)據(jù)，在業(yè)務(wù)層合并結(jié)果。
示例代碼：聚合查詢
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());
}手動(dòng)分片查詢的方案，如果數(shù)據(jù)比較多，性能會(huì)比較差。
3. 分布式事務(wù)問題
問題描述
分布式事務(wù)（如訂單表在庫 A，庫存表在庫 B）無法使用單庫事務(wù)，導(dǎo)致可能會(huì)出現(xiàn)數(shù)據(jù)的一致性問題。
解決方案
3.1 分布式事務(wù)框架
- Seata：支持跨庫的分布式事務(wù)。
- 示例代碼：
@GlobalTransactional
public void createOrder(Order order) {
orderService.saveOrder(order); // 寫入庫A
stockService.reduceStock(order.getProductId()); // 更新庫B
}3.2 柔性事務(wù)
- 使用消息中間件實(shí)現(xiàn)最終一致性。
- 典型實(shí)現(xiàn)：RocketMQ 消息事務(wù)。
4. 分片鍵設(shè)計(jì)問題
問題描述
分片鍵選擇不當(dāng)可能導(dǎo)致數(shù)據(jù)傾斜（熱點(diǎn)問題）或查詢路由效率低。
解決方案
4.1 分片鍵設(shè)計(jì)原則
- 數(shù)據(jù)分布均勻：避免熱點(diǎn)問題。
- 常用查詢字段：盡量選高頻查詢字段。
4.2 路由表
- 維護(hù)全局路由表，映射分片鍵到分表。
示例代碼：路由表查詢
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. 數(shù)據(jù)遷移問題
問題描述
擴(kuò)容（如從 4 個(gè)分片擴(kuò)展到 8 個(gè)分片）時(shí)，舊數(shù)據(jù)需要遷移到新分片，遷移復(fù)雜且可能影響線上服務(wù)。
解決方案
5.1 雙寫策略
- 數(shù)據(jù)遷移期間，舊表和新表同時(shí)寫入。
- 待遷移完成后，切換到新表。
5.2 增量同步
- 使用 Canal 監(jiān)聽 MySQL Binlog，將數(shù)據(jù)遷移到新分片。
示例：Canal 配置
canal.destinations:
example:
mysql:
hostname: localhost
port: 3306
username: root
password: password
kafka:
servers: localhost:9092
topic: example_topic6. 分頁查詢問題
問題描述
分頁查詢需要從多個(gè)分片表合并數(shù)據(jù)，再統(tǒng)一分頁，邏輯復(fù)雜度增加。
解決方案
- 各分片分頁后合并：先按分片分頁查詢，業(yè)務(wù)層合并排序后分頁。
- 中間件支持分頁：如 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());
}但如果分的表太多，可能會(huì)有內(nèi)存占用過多的問題，需要做好控制。
7. 運(yùn)維復(fù)雜性
問題描述
分庫分表后，運(yùn)維難度增加：
- 數(shù)據(jù)庫實(shí)例多，監(jiān)控和備份復(fù)雜。
- 故障排查需要跨多個(gè)庫。
解決方案
- 自動(dòng)化運(yùn)維平臺(tái)：如阿里云 DMS。
- 監(jiān)控工具：使用 Prometheus + Grafana 實(shí)現(xiàn)分片監(jiān)控。
總結(jié)
分庫分表本質(zhì)上是“性能換復(fù)雜度”，它雖然能有效提升系統(tǒng)的性能和擴(kuò)展性，但問題也隨之而來。
分庫分表后帶來的問題總結(jié)如下：
問題 | 解決方案 |
全局唯一 ID | 雪花算法、號(hào)段分配、Leaf |
跨庫跨表查詢 | 中間件支持（如 ShardingSphere）或手動(dòng)合并 |
分布式事務(wù) | 分布式事務(wù)框架（Seata）、消息最終一致性 |
分片鍵設(shè)計(jì)問題 | 路由表或高效分片鍵 |
數(shù)據(jù)遷移問題 | 雙寫策略或增量同步（如 Canal） |
分頁查詢問題 | 分片查詢后合并排序 |
運(yùn)維復(fù)雜性 | 自動(dòng)化工具（DMS）、監(jiān)控工具（Prometheus + Grafana） |
應(yīng)根據(jù)業(yè)務(wù)場(chǎng)景選擇適合的分庫分表策略，并通過工具和技術(shù)方案，解決由此帶來的一些問題，最終實(shí)現(xiàn)系統(tǒng)的高性能與高可靠性。
責(zé)任編輯：武曉燕
來源：
蘇三說技術(shù)
