文章目录
- 一、常见的分库分表策略包括：
- 1）水平分表（Row-based Sharding）
- 2）垂直分表（Column-based Split）
- 3）水平分库（Database Sharding）
- 4）垂直分库（Business-based Split）
- 二、四种分库分表对比速记表（面试杀器）
- 三、第一步：垂直分表（最温和、最先做）
- 1️⃣ 场景判断
- 2️⃣ 表结构拆分
- 设计要点
- 3️⃣ Java 层怎么查？
- 四、第二步：水平分表（真正的性能拐点）
- 1️⃣ 场景判断
- 2️⃣ 分表策略
- 3️⃣ ShardingSphere 配置示例
- 4️⃣ 插入 & 查询
- 四、第三步：垂直分库（系统级演进）
- 1️⃣ 场景判断
- 2️⃣ 分库方案
- 3️⃣ 服务拆分
- 五、第四步：水平分库 + 分表（高并发终极形态）
- 订单库升级
- 六、分库分表带来的“坑”（面试必问）
- 1️⃣ 跨库 Join 怎么办？
- 2️⃣ 分布式事务？
- 3️⃣ 主键 ID 怎么生成？
一、常见的分库分表策略包括：
1）水平分表（Row-based Sharding）
将同一张表的数据按行拆分到多张结构相同的表中，常见按某个分片键（如user_id）取模或区间划分。
示例：
user_0、user_1、user_2……
适合：单表数据量过大
2）垂直分表（Column-based Split）
将一张表的不同字段拆分到多张表中，每张表存储部分字段，通常按照访问频率或字段体量拆分。
示例：
user_base（id、name、phone）user_profile（avatar、intro、address）
适合：字段多、宽表、冷热数据明显
3）水平分库（Database Sharding）
将相同表结构的数据分散到多个数据库实例中，每个库都包含完整表结构，用于分摊读写压力。
示例：
db_user_0、db_user_1
适合：并发高、单库 QPS 扛不住
4）垂直分库（Business-based Split）
按照业务模块或功能维度将数据拆分到不同数据库中，不同库之间的表结构通常不同。
示例：
用户库
订单库
支付库
适合：业务复杂、模块解耦
二、四种分库分表对比速记表（面试杀器）
| 类型 | 拆分维度 | 解决什么问题 | 是否改变表结构 |
|---|---|---|---|
| 水平分表 | 行 | 单表数据量大 | ❌ |
| 垂直分表 | 列 | 表太宽、字段多 | ✅ |
| 水平分库 | 数据量 / 并发 | 单库性能瓶颈 | ❌ |
| 垂直分库 | 业务模块 | 系统解耦、扩展性 | ✅ |
📌一句口诀：
行多用水平，列多用垂直；
库扛不住再分库，业务复杂先垂直。
三、第一步：垂直分表（最温和、最先做）
1️⃣ 场景判断
用户表字段 40+，而 80% 查询只用到基础信息。
📌这是典型“宽表”问题
2️⃣ 表结构拆分
user_base-id-username-phone-status-create_time user_profile-user_id-avatar-address-intro-birthday设计要点
user_base高频访问user_profile低频访问一对一，用
user_id关联
🧠收益
索引更小
查询更快
热数据更集中
3️⃣ Java 层怎么查？
UserBasebase=userBaseMapper.selectById(id);UserProfileprofile=userProfileMapper.selectByUserId(id);四、第二步：水平分表（真正的性能拐点）
1️⃣ 场景判断
order 表数据量：
1 天：200 万 1 年：7 亿+🚨 单表必炸
2️⃣ 分表策略
分片键选择
👉 user_id
原因：
查询订单基本按用户查 避免跨表扫描表设计
order_00 order_01...order_15user_id%163️⃣ ShardingSphere 配置示例
spring:shardingsphere:datasource:names:ds0ds0:type:com.zaxxer.hikari.HikariDataSourcejdbc-url:jdbc:mysql://localhost:3306/order_dbusername:rootpassword:rootrules:sharding:tables:t_order:actual-data-nodes:ds0.t_order_${0..15}table-strategy:standard:sharding-column:user_idsharding-algorithm-name:order-inlinesharding-algorithms:order-inline:type:INLINEprops:algorithm-expression:t_order_${user_id % 16}📌代码层完全无感知
Mapper 还是t_order
4️⃣ 插入 & 查询
orderMapper.insert(order);// 自动路由orderMapper.selectByUserId(userId);// 精准命中四、第三步：垂直分库（系统级演进）
1️⃣ 场景判断
用户模块
订单模块
支付模块
强耦合在一个库，影响稳定性
2️⃣ 分库方案
user_db order_db pay_db🎯一个服务一个库
3️⃣ 服务拆分
user-service → user_db
order-service → order_db
pay-service → pay_db
📌好处
故障隔离
独立扩容
更适合微服务
五、第四步：水平分库 + 分表（高并发终极形态）
订单库升级
order_db_0 order_db_1每一个库：
t_order_0 ~ t_order_15路由规则
user_id % 2 → 库 user_id % 16 → 表六、分库分表带来的“坑”（面试必问）
1️⃣ 跨库 Join 怎么办？
❌ 不支持
✅ 解决方案：
业务聚合
冗余字段
ES / Redis 辅助查询
2️⃣ 分布式事务？
❌ 强一致难
✅ 常用方案：
本地事务 + 消息最终一致
Seata（慎用）
3️⃣ 主键 ID 怎么生成？
❌ 自增 ID 不行
✅ 方案：
雪花算法
号段模式
Redis 原子递增
