关系数据库如何分表

在关系数据库中，“分表”通常是指把原本一张大表拆分成多张结构类似的小表，以提升性能、可维护性或突破单表容量/并发瓶颈。下面从为什么分、怎么分、常见策略、实施要点几个角度系统说明。

一、为什么要分表

常见原因：

• 单表数据量过大（如千万/亿级），查询变慢
• 索引过大，写入/更新变慢
• 热点数据集中，锁竞争严重
• 业务维度天然隔离（如按用户、地区、时间）
• 数据库单实例容量或连接数受限

二、分表的主要方式

1. 水平分表（最常用）

按行拆分：表结构相同，数据按某种规则分散到多张表。

示例：

order_0
order_1
order_2
...

常见分片键（Sharding Key）：

• 用户 ID（user_id % N）
• 时间（按年/月：order_2023、order_2024）
• 地区（order_beijing、order_shanghai）
• 哈希值

✅ 适合：数据量大、写多、查询可带分片键

2. 垂直分表

按列拆分：把频繁访问列和冷数据列分开。

示例：

user_base (id, name, phone)
user_ext  (id, bio, avatar, settings)

✅ 适合：

• 表字段很多
• 部分字段很少被访问
• 大字段（TEXT / BLOB）

3. 冷热分表

按时间或访问频率拆分：

• hot_order（近 3 个月）
• cold_order（历史数据）

✅ 适合：日志、订单、消息类系统

4. 按业务域分表（逻辑分表）

不同业务使用不同表，即使结构类似：

• pay_order
• refund_order

三、常见分表策略

1. 取模分表

table = "order_" + (user_id % 16)

优点：分布均匀
缺点：扩容麻烦（改模数要迁移数据）

2. 范围分表

order_202301
order_202302

优点：易扩容、易归档
缺点：可能热点集中（新表压力大）

3. 哈希分表

对分片键做 hash，再取模，比直接取模更均匀。

4. 一致性哈希（分布式场景）

适合动态扩容，减少数据迁移。

四、分表后的典型问题

1. 跨表查询

• 分页困难
• 聚合（SUM / COUNT）需合并多表
• 排序复杂

✅ 解决：

• 中间件（ShardingSphere、MyCat）
• 冗余汇总表
• 搜索引擎（ES）

2. 主键冲突

不能用自增 ID 直接做全局主键。

✅ 方案：

• 雪花算法（Snowflake）
• UUID
• 分段自增（不同表不同起始值）

3. 事务问题

跨表/跨库事务难保证。

✅ 方案：

• 尽量避免跨表事务
• 最终一致性
• 消息队列

五、实施建议（很重要）

1. 先优化索引和 SQL，再考虑分表
2. 单表 500w–2000w 通常不用急着分
3. 分表键要稳定、高频出现在查询中
4. 能用分区表（Partition）先用分区表
5. 使用中间件降低业务侵入

六、MySQL 分区表 vs 分表

• 分区表：逻辑一张表，物理多文件（对应用透明）
• 分表：多张真实表（更灵活，但复杂）

如果你有具体场景（比如 MySQL 订单表、用户表、日志表），我可以给你直接可用的分表方案。