564 lines
23 KiB
Markdown
564 lines
23 KiB
Markdown
---
|
||
tags: [MySQL, 分库分表, Sharding, Vitess, ShardingSphere, Snowflake]
|
||
create time: 2026-05-16 00:00
|
||
---
|
||
|
||
# 分库分表
|
||
|
||
## 概述
|
||
|
||
想象你开了一家超市，所有商品都放在一个仓库里。当商品只有几千种时，一个仓库绰绰有余；但当商品增长到几十万种，一个仓库就变得拥挤不堪——找货慢、入库堵、仓库还会塌。解决方案很简单：**建多个仓库，按规则分配商品**。这就是分库分表（Sharding）的核心思想。
|
||
|
||
当单库单表的数据量超出 MySQL 的舒适区时，分库分表成为必选方案。但分片不仅是技术决策，更是业务架构的改变——它引入了跨分片查询、分布式 ID、数据重平衡等一系列新问题，每一个都是对团队工程能力的考验。
|
||
|
||
> [!QUESTION] 你真的需要分库分表吗？
|
||
>
|
||
> InnoDB 在单表千万级数据下依然表现优秀。一条合适的联合索引 + 读写分离就能解决 80% 的性能瓶颈。分片引入的复杂度远超收益——跨分片 JOIN、分布式事务、数据倾斜、在线迁移……每一个都是生产环境的深夜警报。**建议仅在以下情况才考虑分片：**
|
||
>
|
||
> 1. 单表已突破 **5000 万行**且增长趋势明显
|
||
> 2. QPS 已接近单机 MySQL 的物理极限（约 1~2 万写入/秒）
|
||
> 3. SSD 存储成本显著上升，无法继续横向扩展
|
||
|
||
## 分片策略总览
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
subgraph "水平分片 Horizontal"
|
||
HS["按用户哈希<br/>user_id % N"]
|
||
HR["按范围 Range<br/>created_at 月份"]
|
||
HL["按列表 List<br/>country IN ('CN','US')"]
|
||
end
|
||
|
||
subgraph "垂直分片 Vertical"
|
||
V1["按业务域拆分<br/>订单库 / 用户库 / 商品库"]
|
||
V2["冷热数据分离<br/>热表 SSD / 冷表 HDD"]
|
||
end
|
||
|
||
style HS fill:#00D866,color:#fff
|
||
style V1 fill:#00B6BC,color:#fff
|
||
```
|
||
|
||
| 维度 | 类比 | 适用场景 | 优点 | 缺点 |
|
||
|------|------|---------|------|------|
|
||
| **Hash 分片** | 按姓名首字母分班 | 均匀写入、分散压力 | 数据分布均匀 | 范围查询需遍历所有分片 |
|
||
| **Range 分片** | 按年份归档文件 | 时间序列、归档场景 | 天然支持范围查询 | 热点数据倾斜（如双 11） |
|
||
| **List 分片** | 按部门分配办公区 | 租户隔离、地域隔离 | 边界清晰、易于运维 | 新增分区需提前规划 |
|
||
| **垂直拆分** | 超市按品类分区 | 多业务混合负载 | 业务解耦、故障隔离 | 跨库 JOIN 变复杂 |
|
||
|
||
> [!TIP] 最佳实践：先垂直再水平
|
||
> 如果不同业务的表耦合在同一库里，先做**垂直拆分**（按业务域拆成多个库），再对单个大表做**水平拆分**。两步都做能最大化收益。
|
||
|
||
## 水平分表实战
|
||
|
||
### Hash 分片
|
||
|
||
```sql
|
||
-- 假设拆分 orders 表为 4 张子表：orders_0 ~ orders_3
|
||
-- 路由规则：order_id % 4 = 表后缀
|
||
-- order_id=1001 → orders_1
|
||
-- order_id=1004 → orders_0
|
||
```
|
||
|
||
```go
|
||
// 通过 order_id 计算目标分片
|
||
func GetShardTableName(orderID int64, shardCount int) string {
|
||
return fmt.Sprintf("orders_%d", orderID%int64(shardCount))
|
||
}
|
||
```
|
||
|
||
> ⚠️ Hash 分片的坑：`order_id` 本身由数据库自增生成——如果你还没上分布式 ID，`order_id` 不能用作分片键（因为它是单库内递增的）。此时应改用 `user_id`（雪花算法生成的分布式 ID）。
|
||
|
||
### Range 分片
|
||
|
||
Range 分片的核心思想是**按连续区间划分**，最典型的场景就是按时间分表——每个月一张表，就像把文件按年份放进不同的文件夹。
|
||
|
||
```sql
|
||
-- 按月分表：审计日志、交易流水等时间序列数据
|
||
-- 表名：logs_202601, logs_202602, ..., logs_202612
|
||
|
||
-- 查询某月数据 → 只需访问一张表
|
||
SELECT * FROM logs_202603 WHERE level = 'ERROR' ORDER BY created_at DESC LIMIT 100;
|
||
|
||
-- 跨月范围查询 → 路由层自动合并多张表
|
||
SELECT * FROM logs_202603
|
||
UNION ALL
|
||
SELECT * FROM logs_202604
|
||
WHERE created_at BETWEEN '2026-03-01' AND '2026-04-30';
|
||
```
|
||
|
||
```go
|
||
// 路由层：根据时间范围计算需要查询哪些表
|
||
func GetLogTableNames(start, end time.Time) []string {
|
||
var tables []string
|
||
for t := start; !t.After(end); t = t.AddDate(0, 1, 0) {
|
||
tables = append(tables, fmt.Sprintf("logs_%s", t.Format("200601")))
|
||
}
|
||
return tables
|
||
}
|
||
```
|
||
|
||
> [!TIP] Range 分片天然适合做数据归档
|
||
> 历史数据可以直接迁移到低成本存储，操作极其简单：
|
||
> ```sql
|
||
> -- 将上月数据归档到 archive 库，腾出 SSD 空间
|
||
> ALTER TABLE logs_202601 RENAME TO archive.logs_202601_old;
|
||
> -- 为下月预创建空表
|
||
> CREATE TABLE logs_202602 LIKE logs_202601;
|
||
> ```
|
||
|
||
> [!QUESTION] Range 分片最大的风险是什么？
|
||
> 答：**数据倾斜**。如果你按月分表，双 11 当天的写入量可能是平时的 100 倍——所有的写入压力集中在一张表上。解决方案：对热点时段做二次 Hash 分片（见下方"联合分片"）。
|
||
|
||
### List 分片
|
||
|
||
List 分片是**按枚举值分组**，最典型的场景是 SaaS 多租户——每个租户的数据天然隔离，互不干扰。就像办公楼按公司分配楼层，A 公司在 3 楼，B 公司在 5 楼。
|
||
|
||
```sql
|
||
-- SaaS 多租户场景：每个租户的数据在独立的库中
|
||
-- tenant_A: db_tenant_0.orders, db_tenant_0.users
|
||
-- tenant_B: db_tenant_1.orders, db_tenant_1.users
|
||
|
||
-- 查询时自动路由到对应库
|
||
-- 应用层根据 tenant_id 选择数据库连接
|
||
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC;
|
||
-- → tenant_A 走 db_tenant_0，tenant_B 走 db_tenant_1
|
||
```
|
||
|
||
```go
|
||
// 路由层：根据租户 ID 选择目标数据库
|
||
func GetTenantDB(tenantID string) *sql.DB {
|
||
// 租户 → 库的映射关系（可存配置中心或 Redis）
|
||
dbMap := map[string]*sql.DB{
|
||
"tenant_A": dbTenant0,
|
||
"tenant_B": dbTenant1,
|
||
}
|
||
return dbMap[tenantID]
|
||
}
|
||
```
|
||
|
||
> [!NOTE] List 分片的额外好处：合规审计
|
||
> 某些行业（金融、医疗）要求租户数据物理隔离。List 分片天然满足这一需求——不同租户的数据在不同物理库中，审计时只需检查对应库即可。
|
||
|
||
### 联合分片
|
||
|
||
单一维度的分片总有局限：Hash 分片不支持范围查询，Range 分片会数据倾斜。**联合分片是两种策略的组合**——用两个（或更多）维度共同决定数据归属。
|
||
|
||
```go
|
||
// 联合分片公式：shard_id = (user_id % 16) * 4 + (month % 4)
|
||
// 第一层 user_id % 16 → 分散写入压力，同一用户的数据集中
|
||
// 第二层 month % 4 → 按时间归档，热点月份自动分散到 4 张表
|
||
// 共 16 × 4 = 64 张子表
|
||
|
||
func GetShardTableName(userID int64, t time.Time) string {
|
||
userShard := userID % 16 // 用户维度：16 个桶
|
||
timeShard := int(t.Month()-1) % 4 // 时间维度：4 个桶
|
||
shardID := userShard*4 + int64(timeShard)
|
||
return fmt.Sprintf("orders_%d", shardID)
|
||
}
|
||
|
||
// 举例：
|
||
// user_id=1001, 2026年3月 → orders_38 (1001%16=9, month=2, 9*4+2=38)
|
||
// user_id=1001, 2026年5月 → orders_36 (1001%16=9, month=4, 9*4+0=36)
|
||
// user_id=2002, 2026年3月 → orders_10 (2002%16=2, month=2, 2*4+2=10)
|
||
// 同一用户不同月份的数据落在相邻分片，方便按用户维度聚合
|
||
```
|
||
|
||
## 分片键选型指南
|
||
|
||
分片键（Sharding Key）是分库分表中最关键的决策——**一旦选定，后期几乎无法更换**。选错了分片键，就像把图书馆的书按"书名首字"分区，找"数据库"相关的书要跑遍 20 个书架。
|
||
|
||
分片键的核心要求只有一个：**让最常用的查询能精确定位到一个分片**，而不是扫描所有分片。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
Start["选定分片键"] --> Q1{"查询是否<br/>总是包含此字段？"}
|
||
|
||
Q1 -->|是| Q2{"数据量是否<br/>分布均匀？"}
|
||
Q1 -->|否| FAIL1["❌ 范围查询需扫描全部分片"]
|
||
|
||
Q2 -->|是| RECOMMEND["✅ 推荐作为分片键"]
|
||
Q2 -->|否| REBALANCE["⚠️ 考虑 List 或 Range 分片"]
|
||
|
||
RECOMMEND --> Q3{"是否有业务<br/>级联删除？"}
|
||
Q3 -->|无| FINAL["🏆 user_id 是最常见的分片键"]
|
||
Q3 -->|有| WARNING["⚠️ 级联操作会触发多分片写"]
|
||
|
||
FAIL1 --> Q4{"是否按时间查询为主？"}
|
||
Q4 -->|是| TIME["✅ Range 按时间分片"]
|
||
Q4 -->|否| TRYDIFF["🔄 换一个能覆盖主查询的字段"]
|
||
```
|
||
|
||
> [!EXAMPLE] 经典案例：电商订单的分片键选择
|
||
> - **错误选择**：`order_id` —— 自增 ID，数据集中在最后一个分片
|
||
> - **正确选择**：`user_id` —— 分布式 ID，天然分散；且 90% 的订单查询都带 `WHERE user_id = ?`
|
||
> - **折中方案**：`(user_id, order_id)` 联合主键，`user_id` 作分片键，`order_id` 作二级索引
|
||
|
||
### 验证分片键的三个问题
|
||
|
||
在决定分片键之前，用这三个问题自检：
|
||
|
||
| # | 问题 | 如果答案是否定的 |
|
||
|---|------|-----------------|
|
||
| 1 | **核心查询路径是否都能带上这个字段？** | 会出现大量跨分片扫描 |
|
||
| 2 | **数据分布是否足够随机化？** | 需要加盐（salt）打散 |
|
||
| 3 | **未来 1~2 年的业务增长是否会改变查询模式？** | 预留可调整空间 |
|
||
|
||
> [!NOTE] 数据倾斜检测
|
||
> ```sql
|
||
> -- 监控每个分片的数据量差异
|
||
> SELECT table_name, table_rows
|
||
> FROM information_schema.tables
|
||
> WHERE table_schema = 'mydb' AND table_name LIKE 'orders_%'
|
||
> ORDER BY table_rows DESC;
|
||
> -- 如果最大分片行数 > 最小分片的 3 倍 → 存在倾斜
|
||
> ```
|
||
|
||
## 分布式 ID 与分片的关系
|
||
|
||
分库分表后，**全局唯一 ID** 是第一道门槛。想象有两个班级各自编号：A 班有 1 号、2 号、3 号……B 班也有 1 号、2 号、3 号……当两个班级合并参加运动会时，"1 号"到底是谁？这就是分库后自增 ID 冲突的问题。
|
||
|
||
> [!IMPORTANT] 主键策略必须适配分片
|
||
>
|
||
> 如果你的主键是 AUTO_INCREMENT，每个分库各自从 1 开始计数——一旦需要合并数据或做跨库查询，ID 冲突不可避免。这就是为什么**要做分片就必须先上分布式 ID**。
|
||
>
|
||
> 详细的 ID 生成方案请参考：[[hhs/MySQL/05-表设计/22-主键策略对比]]（Snowflake、ULID、UUID_TO_BIN 等方案的深度对比）。
|
||
|
||
快速选型参考：
|
||
|
||
| 场景 | 推荐方案 | 理由 |
|
||
|------|---------|------|
|
||
| 已有 Snowflake Worker | 直接用现有 WorkerID | 保持一致性，无需额外组件 |
|
||
| 已有独立 ID 服务 | 调用 gRPC/HTTP ID 接口 | 集中管控，可回拨告警 |
|
||
| 轻量级项目 | MySQL sequence 表 | 简单可靠，但高并发下有瓶颈 |
|
||
|
||
## 跨分片查询
|
||
|
||
这是分库分表最大的痛点。分片前，一个 `JOIN` 就能搞定的查询，分片后可能需要遍历所有分片再手动合并。
|
||
|
||
### 不可行方案
|
||
|
||
```sql
|
||
-- ❌ 跨分片 JOIN：MySQL 的 JOIN 只在同一实例内有效
|
||
-- orders 表在 sharded_db，users 表在 user_db，两个不同的实例
|
||
-- 这条 SQL 会直接报错：Table 'user_db.users' doesn't exist
|
||
SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id;
|
||
|
||
-- ❌ 暴力 UNION ALL：除非你能精确计算分片号，否则必须扫描全部分片
|
||
-- 4 个分片还好，如果有 64 个分片，每次都扫全量就太浪费了
|
||
SELECT * FROM orders_0 WHERE user_id = 100
|
||
UNION ALL SELECT * FROM orders_1 WHERE user_id = 100
|
||
UNION ALL SELECT * FROM orders_2 WHERE user_id = 100
|
||
UNION ALL SELECT * FROM orders_3 WHERE user_id = 100;
|
||
```
|
||
|
||
### 可行方案：应用层 JOIN
|
||
|
||
```go
|
||
// Step 1: 获取用户信息
|
||
userInfo, _ := userService.GetUser(userID)
|
||
|
||
// Step 2: 计算订单所在分片
|
||
shards := []string{fmt.Sprintf("orders_%d", userID%4)}
|
||
|
||
// Step 3: 并发查询各分片
|
||
type OrderResult struct {
|
||
Orders []Order
|
||
Err error
|
||
}
|
||
|
||
ch := make(chan OrderResult, len(shards))
|
||
for _, shard := range shards {
|
||
go func(s string) {
|
||
orders := queryOrders(s, userID)
|
||
ch <- OrderResult{Orders: orders}
|
||
}(shard)
|
||
}
|
||
|
||
var allOrders []Order
|
||
for range shards {
|
||
result := <-ch
|
||
allOrders = append(allOrders, result.Orders...)
|
||
}
|
||
sort.Slice(allOrders, func(i, j int) bool {
|
||
return allOrders[i].CreatedAt.After(allOrders[j].CreatedAt)
|
||
})
|
||
```
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
Client["客户端请求"] --> GW["应用网关<br/>计算目标分片"]
|
||
GW -->|"concurrent"| S1["Query orders_0"]
|
||
GW -->|"concurrent"| S2["Query orders_1"]
|
||
GW -->|"concurrent"| S3["Query orders_2"]
|
||
GW -->|"concurrent"| S4["Query orders_3"]
|
||
S1 & S2 & S3 & S4 --> Merge["合并排序<br/>应用层聚合"]
|
||
Merge --> Resp["返回最终结果"]
|
||
style Merge fill:#FF9F43,color:#000
|
||
```
|
||
|
||
### 跨分片分页（难点中的难点）
|
||
|
||
```sql
|
||
-- ❌ LIMIT 深分页在各分片各自生效，合并后分页结果不对
|
||
-- 分片 0: SELECT * FROM orders_0 ORDER BY id LIMIT 0, 20 → 拿到前 20
|
||
-- 分片 1: SELECT * FROM orders_1 ORDER BY id LIMIT 0, 20 → 拿到前 20
|
||
-- 合并取前 20？→ 错了！实际全局可能有 80 条比这些更早的记录
|
||
|
||
-- ✅ 正确做法：游标分页 + 应用层归并
|
||
-- 每个分片取更大窗口：ORDER BY created_at LIMIT 0, (N+depth)
|
||
-- 应用层全量合并后再截取
|
||
```
|
||
|
||
```go
|
||
// 核心思路：游标分页 + 多路归并
|
||
// 第一步：每个分片多取一些数据（扩大缓冲区）
|
||
// 第二步：应用层合并所有结果，排序后截取需要的条数
|
||
|
||
type PageRequest struct {
|
||
UserID int64
|
||
Limit int // 期望返回条数，比如 20
|
||
AfterTs int64 // 游标：上一页最后一条的时间戳，首次请求传 0
|
||
}
|
||
|
||
func QueryShardedOrders(req PageRequest) ([]Order, error) {
|
||
// 1. 计算目标分片（这里只查 1 个分片，因为 user_id % 4 路由精确）
|
||
shard := fmt.Sprintf("orders_%d", req.UserID%4)
|
||
|
||
// 2. 扩大窗口：请求 20 条，但从每个分片取 40 条作为缓冲
|
||
// 为什么要多取？因为游标边界附近的数据可能分布在不同分片
|
||
bufferSize := req.Limit * 2
|
||
query := fmt.Sprintf(
|
||
"SELECT * FROM %s WHERE user_id = %d AND created_at < %d ORDER BY created_at DESC LIMIT %d",
|
||
shard, req.UserID, req.AfterTs, bufferSize,
|
||
)
|
||
rows, _ := db.Query(getConn(shard), query)
|
||
orders := scanOrders(rows)
|
||
|
||
// 3. 截取需要的数量
|
||
if len(orders) > req.Limit {
|
||
orders = orders[:req.Limit]
|
||
}
|
||
return orders, nil
|
||
}
|
||
|
||
// 当分片键不是查询条件时（比如按时间全局排序），需要扫描所有分片：
|
||
func QueryAllShards(req PageRequest) ([]Order, error) {
|
||
var allOrders []Order
|
||
for i := 0; i < 4; i++ {
|
||
shard := fmt.Sprintf("orders_%d", i)
|
||
query := fmt.Sprintf(
|
||
"SELECT * FROM %s WHERE created_at < %d ORDER BY created_at DESC LIMIT %d",
|
||
shard, req.AfterTs, req.Limit*2,
|
||
)
|
||
rows, _ := db.Query(getConn(shard), query)
|
||
allOrders = append(allOrders, scanOrders(rows)...)
|
||
}
|
||
|
||
// 全局排序 + 截取
|
||
sort.Slice(allOrders, func(i, j int) bool {
|
||
return allOrders[i].CreatedAt.After(allOrders[j].CreatedAt)
|
||
})
|
||
if len(allOrders) > req.Limit {
|
||
allOrders = allOrders[:req.Limit]
|
||
}
|
||
return allOrders, nil
|
||
}
|
||
```
|
||
|
||
> [!QUESTION] 为什么不在数据库层做多分片聚合？
|
||
> 因为每个分片上的 `LIMIT` 只在自己分片范围内有效。举个具体例子：你有 4 个分片，想查全局第 100~120 条数据。如果每个分片执行 `LIMIT 100, 20`，得到的是"每个分片自己排第 100~120 条"——合起来 80 条数据，但它们和全局第 100~120 条完全不同。
|
||
>
|
||
> **正确做法**：从每个分片多取一些数据（扩大窗口），在应用层做全局排序后截取。代价是内存和延迟增加，但这是分布式系统的固有 Trade-off。
|
||
|
||
### 跨分片聚合（COUNT / SUM / AVG）
|
||
|
||
简单聚合（COUNT、SUM、AVG）的思路很直接：**每个分片各自算一遍，应用层再合并**。比如总订单数 = 分片 0 的 COUNT + 分片 1 的 COUNT + ……
|
||
|
||
但 `GROUP BY + 聚合` 就麻烦了——你需要合并各分片的分组结果，逻辑复杂且性能差。**更好的方案是预计算**：
|
||
|
||
```sql
|
||
-- 方案：定时汇总表（cron 每小时执行一次）
|
||
-- 每个分片各自聚合，结果写入同一张汇总表
|
||
INSERT INTO summary_daily (date, total_orders, total_amount)
|
||
SELECT DATE(created_at), COUNT(*), SUM(amount)
|
||
FROM orders_0 GROUP BY DATE(created_at)
|
||
UNION ALL
|
||
SELECT DATE(created_at), COUNT(*), SUM(amount)
|
||
FROM orders_1 GROUP BY DATE(created_at)
|
||
UNION ALL
|
||
SELECT DATE(created_at), COUNT(*), SUM(amount)
|
||
FROM orders_2 GROUP BY DATE(created_at)
|
||
UNION ALL
|
||
SELECT DATE(created_at), COUNT(*), SUM(amount)
|
||
FROM orders_3 GROUP BY DATE(created_at);
|
||
|
||
-- 查询时直接读汇总表，响应速度从"秒级"降到"毫秒级"
|
||
SELECT date, SUM(total_orders), SUM(total_amount)
|
||
FROM summary_daily
|
||
WHERE date BETWEEN '2026-05-01' AND '2026-05-31'
|
||
GROUP BY date;
|
||
```
|
||
|
||
## 中间件方案
|
||
|
||
前面的代码示例都是手动计算分片路由——在生产环境中，我们更常用成熟的中间件来处理分片逻辑。中间件就像一个"智能路由器"：应用发一条普通 SQL，中间件自动帮你拆分、路由、合并结果。
|
||
|
||
| 中间件 | 开发者 | 部署模式 | 核心特点 |
|
||
|--------|-------|---------|---------|
|
||
| **Vitess** | YouTube / Google | Proxy | 透明分片、在线 Re-sharding、K8s 原生 |
|
||
| **ShardingSphere** | Apache | Proxy / JDBC | 功能最全、生态广、Java 生态为主 |
|
||
| **MyCat** | 开源社区 | Proxy | 轻量简单、上手快 |
|
||
| **Cobar** | Alibaba | Proxy | 已停止维护，被 ShardingSphere 取代 |
|
||
|
||
### Vitess 架构
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph App["应用层"]
|
||
GO["Go / Java App"]
|
||
end
|
||
|
||
subgraph VT["Vitess Layer"]
|
||
VTGate["vtgate<br/>SQL 路由 + 连接池"]
|
||
VSchemas["vschema<br/>分片策略定义"]
|
||
end
|
||
|
||
subgraph Shards["MySQL Instances"]
|
||
S1["Shard-0<br/>mysqld-3000 ~ 3002"]
|
||
S2["Shard-1<br/>mysqld-3003 ~ 3005"]
|
||
S3["Shard-2<br/>mysqld-3006 ~ 3008"]
|
||
end
|
||
|
||
GO --> VTGate
|
||
VTGate --> VSchemas
|
||
VSchemas -->|"keyspace/table routing"| S1
|
||
VSchemas -->|"keyspace/table routing"| S2
|
||
VSchemas -->|"keyspace/table routing"| S3
|
||
|
||
style VTGate fill:#00B6BC,color:#fff
|
||
style VSchemas fill:#C44569,color:#fff
|
||
```
|
||
|
||
> [!NOTE] Vitess 的核心优势
|
||
> 1. **透明路由**：应用感知不到分片，SQL 无需改动
|
||
> 2. **在线 Re-sharding**：数据迁移过程不影响线上服务
|
||
> 3. **Global Search**：通过 secondary index 支持全分片搜索
|
||
> 4. **Kubernetes Native**：原生支持 K8s 部署与弹性伸缩
|
||
|
||
## 数据迁移策略
|
||
|
||
**从零停机迁移角度，这是生产环境最关键的一环。**
|
||
|
||
### 双写迁移法（推荐）
|
||
|
||
双写迁移的思路很直观：**新旧两套库同时写入，逐步切换读流量**。就像搬新家时，先把旧家具搬到新房子，同时新旧两个地址都收快递——等新家收拾好了，再把快递地址改成新家。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["旧库 single_db"] --> B["新集群 sharded_db_0..N"]
|
||
|
||
subgraph "Phase 1: 存量数据搬迁"
|
||
P1["离线导出旧表<br/>mysqldump"] --> P2["分批导入新集群<br/>每批 ~100 万行"]
|
||
end
|
||
|
||
subgraph "Phase 2: 双写过渡"
|
||
APP["应用代码"] -->|"读旧+写旧"| P1
|
||
APP -->|"写新(异步)"| B
|
||
NOTE1["新旧数据一致<br/>允许短暂不一致"]
|
||
end
|
||
|
||
subgraph "Phase 3: 切读"
|
||
P3["数据校验工具<br/>row count / checksum"] --> P4["切换读路由到新集群"]
|
||
end
|
||
|
||
subgraph "Phase 4: 清理"
|
||
P5["停止旧库写入"] --> P6["观察 1~2 周无异常<br/>下线旧库"]
|
||
end
|
||
|
||
P1 -.->|阶段顺序| P2 -.->|阶段顺序| P3 -.->|阶段顺序| P4 -.->|阶段顺序| P5 -.->|阶段顺序| P6
|
||
```
|
||
|
||
```go
|
||
// 双写伪代码：写入新集群时走异步通道
|
||
func CreateOrder(order *Order) error {
|
||
// 同步写旧库（保证兼容）
|
||
if err := writeOldDB(order); err != nil {
|
||
return err
|
||
}
|
||
|
||
// 异步写新分片（不阻塞主流程）
|
||
go func() {
|
||
shard := GetShardTableName(order.ID, 4)
|
||
writeNewDB(shard, order)
|
||
}()
|
||
|
||
return nil
|
||
}
|
||
```
|
||
|
||
### 渐进式迁移（适合超大表）
|
||
|
||
渐进式迁移的核心思想是**分批切换**——先迁移一部分流量到新集群，验证无误后再迁移下一批，最终全部切完。就像搬办公室：先把一个部门搬过去，安顿好了再搬下一个，而不是一次性把整层楼的人都搬走。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph Init["初始状态"]
|
||
AllOld["全部流量"] --> OldDB["老库"]
|
||
end
|
||
|
||
subgraph P1["Phase 1: 50% 流量"]
|
||
P1Even["hash(user_id) % 2 == 0"] --> NewS01["新分片 0,1"]
|
||
P1Odd["hash(user_id) % 2 == 1"] --> OldDB2["老库"]
|
||
end
|
||
|
||
subgraph P2["Phase 2: 100% 流量"]
|
||
P2A["hash(user_id) % 4 == 0,1"] --> NewS01B["新分片 0,1"]
|
||
P2B["hash(user_id) % 4 == 2,3"] --> NewS23["新分片 2,3"]
|
||
end
|
||
|
||
Init -->|"Phase 1: 先切一半"| P1
|
||
P1 -->|"Phase 2: 再切剩余"| P2
|
||
|
||
style P1 fill:#FFEAA7,color:#000
|
||
style P2 fill:#00D866,color:#fff
|
||
```
|
||
|
||
> [!TIP] 渐进式迁移的核心优势
|
||
> - **风险可控**：每次只影响部分用户，出问题时只需回滚那部分流量
|
||
> - **可灰度验证**：先选一小批内部用户试跑，确认无误后再扩大范围
|
||
> - **无需停机**：整个过程对用户透明，业务零感知
|
||
>
|
||
> 劣势：需要在应用层维护两套路由规则，增加了代码复杂度。
|
||
|
||
> [!WARNING] 迁移 checklist
|
||
>
|
||
> - [ ] DDL 变更兼容性：旧版代码能否读取新表结构？（永远先加字段、后删字段）
|
||
> - [ ] 数据校验：用 `pt-table-checksum` 比对新旧数据一致性
|
||
> - [ ] 回滚预案：切到新集群后发现问题，能在 5 分钟内切回
|
||
> - [ ] 索引重建：新分片是否需要不同的索引策略？
|
||
> - [ ] 监控接入：分片后的慢查询监控面板是否就绪？
|
||
|
||
## 分片的挑战与反模式
|
||
|
||
分库分表不是银弹，它解决了一个问题，却引入了更多问题。下表列出了最常见的"坑"和应对策略：
|
||
|
||
| 问题 | 具体表现 | 应对策略 |
|
||
|------|---------|---------|
|
||
| **数据倾斜** | 某些分片数据量远大于其他（比如大卖家的订单集中在某个分片） | 检查 hash 分布，必要时换分片键或加 salt 打散 |
|
||
| **跨分片事务** | 一笔业务涉及多个分片，InnoDB 不支持跨库事务 | 用 Saga / TCC / 消息队列补偿（见 [[hhs/MySQL/08-工程实践/36-分布式事务]]) |
|
||
| **Rebalance** | 新增节点后，老数据如何迁移到新分片？ | 渐进式迁移，Vitess 内置 Scatter-Gather |
|
||
| **复杂聚合** | COUNT / SUM 跨分片很贵，GROUP BY 更是噩梦 | 预计算 + 定时汇总到汇总表（见上方详解） |
|
||
| **分页困难** | LIMIT 深分页在各分片各自生效，合并后结果不对 | 游标分页 + 应用层合并（见上方详解） |
|
||
| **全局唯一约束** | UNIQUE KEY 在多分片下失效（两个分片可能各插入同一条） | 改为业务层面去重，或用 Redis SET |
|
||
|
||
> [!WARNING] 别过早分片
|
||
>
|
||
> 再次强调：**90% 的项目永远不需要分库分表**。InnoDB 单表千万级性能依然优秀。只有在满足前述三个条件时才考虑分片。如果团队规模小、迭代快，花两周优化 SQL 和索引的收益远高于花一个月做分片架构。
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/MySQL/05-表设计/22-主键策略对比]] — 分布式 ID 生成方案（Snowflake / ULID / UUID）
|
||
- [[hhs/GORM/13-多数据库支持]] — GORM 对多库连接的支持
|
||
- [[hhs/MySQL/08-工程实践/35-Go 连接池配置]] — 多分片场景下的连接池隔离
|
||
- [[hhs/MySQL/08-工程实践/38-监控指标]] — 分片集群的监控指标体系
|