数据库OLTP怎么做分库分表

在数据库领域，OLTP（联机事务处理）系统通常面临高并发、低延迟、强一致性的要求。当单库单表在数据量或并发上遇到瓶颈时，就需要做分库分表（Sharding）。下面从“为什么做、怎么做、关键问题、常见方案”几个角度系统说明。

一、为什么要分库分表（OLTP 场景）

典型瓶颈：

• 单表数据量过大（如超过千万/亿级），索引变大、查询变慢
• 单库连接数、CPU、IO 达到上限
• 写热点集中，锁竞争严重

目标：

• 降低单表数据量
• 分散读写压力
• 提高系统吞吐和可用性

二、分库分表的核心思路

1. 分表（同一库内）

• 解决单表过大问题
• 如表 order → order_00 ~ order_31

2. 分库（跨实例）

• 解决单库资源瓶颈
• 如 db0 ~ db3，每个库含若干分表

3. 分库 + 分表（最常见）

• 既分库又分表，扩展性和性能最好

三、分片策略（怎么切）

1. 按主键 / 业务键哈希（最常用）

shard_key = user_id
db_index  = hash(user_id) % 4
tbl_index = hash(user_id) % 32

优点：

• 数据分布均匀
• 避免热点

缺点：

• 范围查询不方便

2. 按时间分片（适合日志/订单）

order_202401
order_202402

优点：

• 冷热数据清晰
• 易于归档

缺点：

• 最新表容易成为写热点

3. 按范围分片

user_id 1~1000w → db0
user_id 1000w~2000w → db1

优点：

• 范围查询友好

缺点：

• 容易数据倾斜

4. 基因法（推荐用于关联表）

例如：

• user_id 决定分片
• order_id 中包含 user_id 的分片基因

这样可以用 order_id 直接定位库表，避免跨库 JOIN。

四、OLTP 分库分表的关键问题

1. 分片键（Sharding Key）选择 ⭐

原则：

• 高频查询条件
• 写操作均匀
• 尽量避免跨片

反例：

• 用 create_time 做分片键但按 user_id 查询

2. 跨库 JOIN

OLTP 中尽量避免：

• 只查单分片（最优）
• 冗余字段（空间换时间）
• 异构索引表（如 user→order 映射表）

3. 分布式事务

OLTP 要求强一致时：

• 尽量单库事务
• 跨库用：
  • 最终一致（消息队列）
  • TCC / Saga
  • 少用 2PC（性能差）

4. 全局唯一 ID

不能用单库自增：

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

5. 分页与排序

跨分片分页很贵：

• 每个分片查 → 内存归并
• 限制深度分页
• 用游标 / 上次最大 ID

五、常见实现方案

1. 中间件层（最常用）

• ShardingSphere（强烈推荐）
• MyCat
• Vitess（MySQL + Kubernetes）

优点：

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

2. 应用层分片

• 自己写路由逻辑
• 灵活但维护成本高

3. 数据库原生

• MySQL 本身不支持自动分库分表
• PostgreSQL + Citus（分布式 OLTP 可选）

六、OLTP 分库分表建议顺序

1. 先优化：
   • 索引
   • SQL
   • 缓存（Redis）
   • 读写分离
2. 再考虑：
   • 单表分区
3. 最后：
   • 分库分表（成本高，慎早做）

七、一句话总结

OLTP 分库分表的核心不是“切成几块”，而是选对分片键、避免跨库、控制复杂度。

如果你愿意，可以告诉我：

• 用的数据库（MySQL / PG / Oracle）
• 数据量和 QPS
• 典型 SQL

我可以直接帮你设计一套分库分表方案。