分库分表（一）

假设目前有一张表order 订单表，需要分库分表，举例给出方案设计，并解决上述提到的分库分表带来的问题，详细说明

下面给你用一个比较接近真实互联网生产环境的例子来说明：
假设有一张order 订单表，数据量增长很快，需要进行分库分表设计，并解决分库分表带来的问题。

我会按照一个完整架构设计步骤说明：

1️⃣ 业务背景
2️⃣ 分库分表方案设计
3️⃣ 路由规则设计
4️⃣ 全局ID方案
5️⃣ 解决跨库查询
6️⃣ 解决跨库事务
7️⃣ 解决扩容问题
8️⃣ 架构总结

一、业务背景

假设一个电商系统订单表：

CREATE TABLE order (
id BIGINT PRIMARY KEY,
user_id BIGINT,
product_id BIGINT,
price DECIMAL(10,2),
status INT,
create_time DATETIME
);

业务规模：

问题：

• 单表数据量巨大

• 索引非常大

• 查询变慢

• 写入压力大

所以需要分库分表。

二、分库分表总体方案

设计：

8个库
每个库16张表

总共：

8 × 16 = 128张表

结构示例：

order_db_0
order_0
order_1
...
order_15

order_db_1
order_0
order_1
...
order_15

整体架构：

应用
|
分库分表中间件
|
-------------------------------
| | | | |
db0 db1 db2 ... db7

可以使用：

• ShardingSphere

• MyCat

• Vitess

或应用层实现。

三、分库分表规则设计（核心）

选择分片键：

user_id

原因：

• 用户查询订单最频繁

• 用户订单通常一起查询

分库规则

db_index = user_id % 8

示例：

分表规则

table_index = order_id % 16

例如：

order_id = 123456

计算：

123456 % 16 = 0

所以：

order_db_1.order_0

完整路由流程：

user_id → 计算库
order_id → 计算表

四、全局ID问题解决

问题：

如果每个库使用：

auto_increment

会出现：

db0.order id=1
db1.order id=1

ID冲突。

解决方案：Snowflake算法

Snowflake 64位ID结构：

1bit 符号位
41bit 时间戳
10bit 机器ID
12bit 序列号

生成ID示例：

175928847299117063

优点：

• 全局唯一

• 趋势递增

• 不依赖数据库

生成流程：

应用
↓
ID生成服务
↓
返回order_id
↓
写入数据库

五、跨库查询问题解决

原SQL：

select count(*) from order;

分表后：

order_0
order_1
...
order_15

无法直接查询。

方案1：中间件聚合

例如：

ShardingSphere 自动执行：

查询所有表
↓
合并结果

流程：

应用
↓
中间件
↓
查询128张表
↓
聚合结果

方案2：建立统计表

例如：

order_stat

结构：

date
order_count
amount

订单创建时：

订单服务
↓
写订单表
↓
更新统计表

查询统计直接：

select order_count from order_stat;

六、跨库JOIN问题解决

原SQL：

select *
from order o
join user u on o.user_id = u.id;

如果：

order_db
user_db

数据库无法 join。

解决方案1：应用层join

流程：

查订单
↓
获取user_id
↓
调用用户服务
↓
获取用户信息

解决方案2：数据冗余

订单表冗余用户信息：

order
user_id
user_name
user_level

这样查询：

select user_name from order;

不需要 join。

七、分布式事务问题解决

假设订单和库存：

订单库
库存库

原事务：

begin
insert order
update stock
commit

跨库后无法保证事务。

方案：消息最终一致性

流程：

创建订单
↓
写订单表
↓
发送MQ消息
↓
库存服务消费消息
↓
扣减库存

如果失败：

重试
补偿

常用MQ：

• Kafka

• RocketMQ

• RabbitMQ

八、扩容问题解决

如果最初：

4个库

路由：

user_id % 4

扩容到：

8个库

会导致大量数据迁移。

解决方案：一致性Hash

结构：

hash ring

优点：

• 只迁移少量数据

• 扩容平滑

或者：

预留库数量

例如：

最初设计16个库
先使用8个

九、分页排序问题

原SQL：

select *
from order
order by create_time
limit 10;

分表后：

流程：

每个表取10条
↓
应用层汇总
↓
排序
↓
取前10

很多中间件支持这种merge sort。

十、最终架构图

完整系统：

用户
|
网关
|
订单服务
|
分库分表中间件
|
-----------------------------------------
| | | | | |
db0 db1 db2 db3 ... db7

辅助系统：

ID生成服务
消息队列
缓存Redis
监控系统

十一、总结

订单系统分库分表设计：

核心原则：

用分库分表解决数据规模问题
用分布式架构解决带来的复杂度