456 lines
17 KiB
Markdown
456 lines
17 KiB
Markdown
---
|
||
tags: [MySQL, 分库分表, Sharding, Vitess, ShardingSphere, Snowflake]
|
||
create time: 2026-05-16 00:00
|
||
---
|
||
|
||
# 分库分表
|
||
|
||
## 概述
|
||
|
||
当单库单表的百万级数据无法满足性能需求时，分库分表（Sharding）成为必选方案。但分片不仅是技术决策，更是业务架构的改变——它引入了跨分片查询、分布式 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 分片
|
||
|
||
```sql
|
||
-- 按月分表（适合审计日志、交易流水等时间序列数据）
|
||
-- logs_202601, logs_202602, ..., logs_202612
|
||
-- 优势：天然支持范围查询 WHERE created_at BETWEEN ...
|
||
-- 劣势：最近月份写入压力大，历史月份只有读取
|
||
```
|
||
|
||
```sql
|
||
-- 利用 range 分片的特性做数据归档
|
||
-- 每月 1 号自动将上月数据迁移到 archive 库
|
||
ALTER TABLE logs_202601 RENAME TO archive.logs_202601_old;
|
||
CREATE TABLE logs_202602 LIKE logs_202601;
|
||
```
|
||
|
||
### List 分片
|
||
|
||
```sql
|
||
-- 按 tenant_id 列表拆分（SaaS 多租户场景）
|
||
-- tenant_A 的所有表在一个库，tenant_B 在另一个库
|
||
-- 优势：租户级别的数据隔离，方便合规审查
|
||
-- tenant_A: db_tenant_0.tenant_A_users, db_tenant_0.tenant_A_orders
|
||
-- tenant_B: db_tenant_1.tenant_B_users, db_tenant_1.tenant_B_orders
|
||
```
|
||
|
||
### 联合分片
|
||
|
||
```sql
|
||
-- 双维度分片：shard_id = (user_id % 16) * 4 + (month % 4)
|
||
-- 第一层 user_id 哈希：分散写入压力，同一用户的记录集中
|
||
-- 第二层 month 取模：便于按时间范围和归档
|
||
-- 共 16 × 4 = 64 张子表
|
||
```
|
||
|
||
## 分片键选型指南
|
||
|
||
分片键是选择最关键的决策——**一旦选定，后期几乎无法更换**。
|
||
|
||
```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** 是第一道门槛。每个分片的自增 ID 只在本地有意义，合并时必然冲突。
|
||
|
||
> [!IMPORTANT] 主键策略必须适配分片
|
||
>
|
||
> 如果你的主键是 AUTO_INCREMENT，每个分库各自从 1 开始计数——一旦需要合并数据或做跨库查询，ID 冲突不可避免。这就是为什么**要做分片就必须先上分布式 ID**。
|
||
>
|
||
> 详细的 ID 生成方案请参考：[[hhs/MySQL/09-主键策略对比]]（Snowflake、ULID、UUID_TO_BIN 等方案的深度对比）。
|
||
|
||
快速选型参考：
|
||
|
||
| 场景 | 推荐方案 | 理由 |
|
||
|------|---------|------|
|
||
| 已有 Snowflake Worker | 直接用现有 WorkerID | 保持一致性，无需额外组件 |
|
||
| 已有独立 ID 服务 | 调用 gRPC/HTTP ID 接口 | 集中管控，可回拨告警 |
|
||
| 轻量级项目 | MySQL sequence 表 | 简单可靠，但高并发下有瓶颈 |
|
||
|
||
## 跨分片查询
|
||
|
||
这是分库分表最大的痛点。
|
||
|
||
### 不可行方案
|
||
|
||
```sql
|
||
-- ❌ JOIN 跨分片：MySQL 原生不支持分布式 JOIN
|
||
-- 一个表在 sharded_db.orders_0..3，另一个在 user_db.users
|
||
|
||
-- ❌ UNION ALL 拼全部分片（除非你知道具体分片号）
|
||
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
|
||
// 游标分页 + 多路归并排序
|
||
// 类似 Git rebase 的多分支合并逻辑
|
||
|
||
type PageRequest struct {
|
||
UserID int64
|
||
Limit int // 期望返回数量
|
||
AfterTs int64 // 游标：上次最后一条的时间戳
|
||
}
|
||
|
||
func QueryShardedOrders(req PageRequest) ([]Order, error) {
|
||
shards := []string{fmt.Sprintf("orders_%d", req.UserID%4)}
|
||
|
||
// Step 1: 各分片拉取 (Limit + Depth) 条数据
|
||
type RawPage struct {
|
||
Shard string
|
||
Orders []Order
|
||
}
|
||
|
||
var allPages []RawPage
|
||
for _, shard := range shards {
|
||
q := 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, req.Limit*2, // 扩大 2 倍缓冲
|
||
)
|
||
rows, _ := db.Query(shardDBConn(shard), q)
|
||
orders := scanOrders(rows)
|
||
allPages = append(allPages, RawPage{shard, orders})
|
||
}
|
||
|
||
// Step 2: 多路归并（k-way merge）
|
||
merged := mergeSort(allPages, req.Limit)
|
||
return merged, nil
|
||
}
|
||
|
||
// k-way merge：类似归并排序的 merge 步骤
|
||
func mergeSort(pages []RawPage, limit int) []Order {
|
||
all := make([]Order, 0, len(pages)*limit)
|
||
for _, p := range pages {
|
||
all = append(all, p.Orders...)
|
||
}
|
||
sort.Slice(all, func(i, j int) bool {
|
||
return all[i].CreatedAt.After(all[j].CreatedAt)
|
||
})
|
||
if len(all) > limit {
|
||
return all[:limit]
|
||
}
|
||
return all
|
||
}
|
||
```
|
||
|
||
> [!QUESTION] 为什么不在数据库层做多分片聚合？
|
||
> 因为每个分片上的 `LIMIT` 只在自己分片范围内有效。想象你有 4 个桶，每个桶倒出前 20 颗珠子，合起来 80 颗里取前 20——但如果你要的是「全局第 1000~1020 颗」，每个桶自己取前 20 完全不够。**解决方案是加大每片采集窗口，然后在应用层做全局排序截断。** 代价是内存和延迟增加，但这是分布式系统的固有 Trade-off。
|
||
|
||
### 跨分片聚合（COUNT / SUM / AVG）
|
||
|
||
```sql
|
||
-- ❌ COUNT(*) 在单个分片运行，汇总时直接相加即可
|
||
-- ✅ 聚合类查询：SUM(xxx) → 各分片算完再 SUM
|
||
|
||
-- 但复杂聚合（GROUP BY + JOIN）会很贵
|
||
-- 方案：预计算 + 定时汇总表
|
||
-- 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);
|
||
```
|
||
|
||
## 中间件方案
|
||
|
||
| 中间件 | 开发者 | 部署模式 | 核心特点 |
|
||
|--------|-------|---------|---------|
|
||
| **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
|
||
}
|
||
```
|
||
|
||
### 渐进式迁移（适合超大表）
|
||
|
||
```
|
||
┌──────────────────────────────────────────────────┐
|
||
│ 渐进式迁移：按分片逐步切换 │
|
||
│ │
|
||
│ 初始: 全部流量 → 老库 │
|
||
│ Phase 1: hash(user_id) % 2 == 0 → 新分片 0,1 │
|
||
│ hash(user_id) % 2 == 1 → 老库 │
|
||
│ Phase 2: hash(user_id) % 4 = 0,1 → 新分片 0,1 │
|
||
│ hash(user_id) % 4 = 2,3 → 新分片 2,3 │
|
||
│ Final: 全部流量 → 新集群 │
|
||
│ │
|
||
│ 优势：每次切换只影响部分用户，风险可控 │
|
||
│ 劣势：需要在应用层维护两套路由规则 │
|
||
└──────────────────────────────────────────────────┘
|
||
```
|
||
|
||
> [!WARNING] 迁移 checklist
|
||
>
|
||
> - [ ] DDL 变更兼容性：旧版代码能否读取新表结构？（永远先加字段、后删字段）
|
||
> - [ ] 数据校验：用 `pt-table-checksum` 比对新旧数据一致性
|
||
> - [ ] 回滚预案：切到新集群后发现问题，能在 5 分钟内切回
|
||
> - [ ] 索引重建：新分片是否需要不同的索引策略？
|
||
> - [ ] 监控接入：分片后的慢查询监控面板是否就绪？
|
||
|
||
## 分片的挑战与反模式
|
||
|
||
| 问题 | 描述 | 应对策略 |
|
||
|------|------|---------|
|
||
| **数据倾斜** | 某些分片数据量远大于其他 | 检查 hash 分布，必要时换分片键或加 salt |
|
||
| **跨分片事务** | InnoDB 不支持跨库事务 | 用 Saga / TCC / 消息队列补偿 |
|
||
| **Rebalance** | 新增节点后数据如何迁移 | 渐进式迁移，Vitess 内置 Scatter-Gather |
|
||
| **复杂聚合** | COUNT / SUM 跨分片很贵 | 预计算 + 定时汇总到汇总表 |
|
||
| **分页困难** | LIMIT 深分页在各分片各自生效 | 游标分页 + 应用层合并（见上方详解） |
|
||
| **全局唯一约束** | UNIQUE KEY 在多分片下失效 | 改为业务层面去重，或用 Redis SET |
|
||
|
||
> [!WARNING] 别过早分片
|
||
>
|
||
> 再次强调：**90% 的项目永远不需要分库分表**。InnoDB 单表千万级性能依然优秀。只有在满足前述三个条件时才考虑分片。如果团队规模小、迭代快，花两周优化 SQL 和索引的收益远高于花一个月做分片架构。
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/MySQL/09-主键策略对比]] — 分布式 ID 生成方案（Snowflake / ULID / UUID）
|
||
- [[hhs/GORM/13-多数据库支持]] — GORM 对多库连接的支持
|
||
- [[hhs/MySQL/35-Go 连接池配置]] — 多分片场景下的连接池隔离
|
||
- [[hhs/MySQL/38-监控指标]] — 分片集群的监控指标体系
|