关系数据库如何进行分库分表

关系数据库在进行分库分表（Sharding / Partitioning）时，核心目标是解决单库单表数据量过大、并发过高、存储和性能瓶颈的问题。下面从概念、拆分方式、路由策略、实施难点和常见方案几个层面系统说明。

一、什么是分库分表

• 分库：把一个数据库拆成多个数据库（通常部署在不同实例/机器上）
• 分表：把一张大表拆成多张结构相同的表（仍在同库或不同库）

常见组合：

• 只分表不分库
• 只分库不分表
• 既分库又分表（大规模系统最常见）

二、常见拆分方式

1. 垂直拆分（按业务/字段）

垂直分库

按业务模块拆分：

user_db
order_db
product_db

垂直分表

按字段访问频率拆分：

user_base (id, name, age)
user_ext (id, avatar, description)

✅ 优点：

• 降低单表字段宽度
• 提升缓存命中率

❌ 缺点：

• 不能解决单表数据量大的问题

2. 水平拆分（按数据行）

将同一张表的数据按某种规则分散到多张表/库中：

order_0
order_1
order_2
...
order_15

✅ 优点：

• 真正解决数据量和并发问题

❌ 缺点：

• 跨分片查询复杂
• 事务、Join 困难

三、水平拆分的关键：分片键（Sharding Key）

选择一个高频查询条件字段作为分片键，例如：

• 用户ID（user_id）
• 订单ID（order_id）
• 时间（create_time）

常见分片算法

1. 取模分片

db_index = user_id % 4

简单，但扩容麻烦

2. 范围分片

202301 ~ 202306 → db1
202307 ~ 202312 → db2

适合时间序列数据

3. 哈希分片

hash(user_id) % N

分布更均匀

4. 一致性哈希

适合动态扩容的分布式系统

四、分库分表后的典型问题

1. 跨分片查询

• 不支持跨库 JOIN
• 常用方案：
  • 冗余字段
  • 异步聚合
  • ES / OLAP 辅助查询

2. 分布式事务

• 本地事务失效
• 解决方案：
  • 最终一致性（MQ）
  • TCC
  • Seata（AT 模式）

3. 全局唯一 ID

不能用数据库自增 常见方案：

• Snowflake
• UUID
• 号段模式（Leaf）

4. 扩容问题

• 取模分片扩容需要数据迁移
• 推荐使用一致性哈希 + 虚拟节点

五、常见技术实现方案

1. 中间件方案（最常用）

• ShardingSphere（JDBC / Proxy）
• MyCat
• Vitess（MySQL 大规模）

✅ 对业务代码侵入小
✅ 支持分库分表、读写分离

2. 应用层自己实现

• 在 DAO 层计算分片
• 简单系统可用
• 维护成本高

3. 云原生方案

• PolarDB
• TiDB（天然分布式）
• OceanBase

六、什么时候该分库分表？

✅ 单表数据 > 1000万
✅ 单库 QPS 明显瓶颈
✅ 数据库 CPU / IO 持续高位

❌ 不要过早分库分表（复杂度指数级上升）

七、总结一句话

分库分表不是银弹，而是架构权衡；先优化索引、SQL、缓存，再考虑分片。

如果你愿意，我可以：

• 帮你设计一个具体业务的分库分表方案
• 对比 ShardingSphere vs MyCat
• 讲一个电商订单系统的真实拆分案例