聊聊分库分表
# 聊聊分库分表
# 如何分库或分表?
类型 | 拆的是什么 | 拆的方式 | 举例 |
---|---|---|---|
✅ 垂直分库 | 按“业务模块”拆库 | 不同模块放不同库 | 用户库、订单库、日志库 |
✅ 水平分库 | 按“数据量”拆库 | 相同结构,分布到多个库 | 用户数据分到 user_db_0 , user_db_1 |
✅ 垂直分表 | 按“表结构”拆表 | 一张大表拆成多个小表 | 用户表拆成:user_base + user_login |
✅ 水平分表 | 按“数据量”拆表 | 同结构,数据按规则分布 | order_0 , order_1 , ..., order_15 |
# 图解理解
垂直分库: 水平分库:
[原始DB] [原始DB]
├─ user ├─ user (1亿)
├─ order => 拆成
├─ product ├─ user_0 (0~5000万)
↓ └─ user_1 (5000万~1亿)
拆成:
[user_db] → user [user_db_0] → user
[order_db] → order [user_db_1] → user
垂直分表: 水平分表:
[User] [Order] (10亿)
├─ id =>
├─ name ├─ order_0
├─ email ├─ order_1
├─ password ...
↓
拆成:
[user_base] → id, name, email
[user_login] → user_id, password
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 每种方式的目的和适用场景
# 1. 垂直分库
场景 | 内容 |
---|---|
拆分维度 | 业务模块或功能模块 |
目的 | 解耦、减轻数据库压力、方便运维 |
举例 | 用户模块放 user_db ,订单模块放 order_db ,日志模块放 log_db |
👉 适合中台系统、模块化微服务架构,让各模块独立开发、部署、扩展。
# 2. 水平分库
场景 | 数据量非常大,单库压力大 |
---|---|
拆分维度 | 相同结构的表,按规则拆到多个库中 |
举例 | user 表有 2 亿数据 → 分到 4 个库,每库 5000 万 |
👉 通常结合分表一起使用(水平分库 + 水平分表)。
# 3. 垂直分表
场景 | 表字段太多、部分字段访问频率极低 |
---|---|
拆分方式 | 把冷字段拆出去,按字段功能分类 |
举例 | 用户表拆成 user_profile 、user_login 、user_settings 表 |
👉 适用于做冷热分离、读写优化、字段稀疏的场景。
# 4. 水平分表
场景 | 单表数据量太大(>千万),查询慢 |
---|---|
拆分方式 | 按 ID、时间、用户ID 等维度将一张大表拆为多个小表 |
举例 | order 表按月份分成 order_202401 ~ order_202412 |
👉 最常见的拆分方式,适用于订单、日志、告警、交易流水等海量数据表。
# 总结对比表
类型 | 拆分维度 | 目标 | 难度 | 常见场景 |
---|---|---|---|---|
垂直分库 | 按模块 | 解耦+并发 | 中等 | 用户、订单分库 |
水平分库 | 按数据 | 扩展性 | 高 | 超大用户/订单表 |
垂直分表 | 按字段 | 热冷分离 | 低 | 用户信息表 |
水平分表 | 按数据 | 降低单表压力 | 中等 | 日志、订单、记录表 |
# 最佳实践建议
- 优先做垂直分库:随着业务模块增加,自然会拆出多个模块库。
- 热点大表做水平分表:例如订单、日志等,千万级时开始规划。
- 使用 ShardingSphere 等中间件:简化路由、分库分表维护。
- 统一 ID 生成器:所有分库分表都需要全局唯一 ID(如雪花算法)。
# 学习参考
上次更新: 2025/5/23 19:28:34