10亿订单如何做分库分表？

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料： 

• 《项目实战（视频）》：从书中学，往事上“练”

• 《互联网高频面试题》：面朝简历学习，春暖花开

• 《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题

• 《精进 Java 学习指南》：系统学习，互联网主流技术栈

• 《必读 Java 源码专栏》：知其然，知其所以然

👉这是一个或许对你有用的开源项目

国产Star破10w的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构

RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能：

• 多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro

• 微服务：https://gitee.com/zhijiantianya/yudao-cloud

• 视频教程：https://doc.iocoder.cn

【国内首批】支持 JDK17/21+SpringBoot3、JDK8/11+Spring Boot2双版本 

来源：苏三说技术

• 1 分库分表核心策略

• • 1.1 垂直拆分：先给数据做减法

  • 1.2 水平拆分：终极解决方案

• 2 基因分片

• 3 跨分片查询

• • 3.1 异构索引表方案

• 4、数据迁移

• 5、避坑指南

• • 5.1 热点问题

  • 5.2 分布式事务

  • 5.3 分页陷阱

• 6 终极架构方案

• 总结

---

场景痛点 ：某电商平台的MySQL订单表达到7亿行时，出现致命问题：

-- 简单查询竟需12秒！
SELECT * FROM orders WHERE user_id=10086 LIMIT 10;

-- 统计全表耗时278秒
SELECT COUNT(*) FROM orders;

核心矛盾 ：

1. B+树索引深度达到5层，磁盘IO暴增。

2. 单表超200GB导致备份时间窗突破6小时。

3. 写并发量达8000QPS，主从延迟高达15分钟。

关键认知 ：当单表数据量突破5000万行 时，就该启动分库分表设计预案。

那么问题来了，假如现在有10亿的订单数据，我们该如何做分库分表呢？

今天这篇文章就跟大家一起聊聊这个问题，希望对你会有所帮助。

1 分库分表核心策略

1.1 垂直拆分：先给数据做减法

优化效果 ：

• 核心表体积减少60%

• 高频查询字段集中提升缓存命中率

1.2 水平拆分：终极解决方案

分片键选择三原则 ：

1. 离散性 ：避免数据热点（如user_id优于status）

2. 业务相关性 ：80%查询需携带该字段

3. 稳定性 ：值不随业务变更（避免使用手机号）

分片策略对比 ：

策略类型	适用场景	扩容复杂度	示例
范围分片	带时间范围的查询	简单	create_time按月分表
哈希取模	均匀分布	困难	user_id % 128
一致性哈希	动态扩容	中等	使用Ketama算法
基因分片	避免跨分片查询	复杂	从user_id提取分库基因

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro

• 视频教程：https://doc.iocoder.cn/video/

2 基因分片

针对订单系统的三大高频查询：

1. 用户查历史订单（user_id）

2. 商家查订单（merchant_id）

3. 客服按订单号查询（order_no）

解决方案 ：

Snowflake订单ID改造 ：

// 基因分片ID生成器
publicclass OrderIdGenerator {
    // 64位ID结构：符号位(1)+时间戳(41)+分片基因(12)+序列号(10)
    privatestaticfinalint GENE_BITS = 12;
    
    public static long generateId(long userId) {
        long timestamp = System.currentTimeMillis() - 1288834974657L;
        // 提取用户ID后12位作为基因
        long gene = userId & ((1 << GENE_BITS) - 1); 
        long sequence = ... // 获取序列号
        
        return (timestamp << 22) 
             | (gene << 10) 
             | sequence;
    }
    
    // 从订单ID反推分片位置
    public static int getShardKey(long orderId) {
        return (int) ((orderId >> 10) & 0xFFF); // 提取中间12位
    }
}

路由逻辑 ：

// 分库分表路由引擎
publicclass OrderShardingRouter {
    // 分8个库 每个库16张表
    privatestaticfinalint DB_COUNT = 8; 
    privatestaticfinalint TABLE_COUNT_PER_DB = 16;
    
    public static String route(long orderId) {
        int gene = OrderIdGenerator.getShardKey(orderId);
        int dbIndex = gene % DB_COUNT;
        int tableIndex = gene % TABLE_COUNT_PER_DB;
        
        return"order_db_" + dbIndex + ".orders_" + tableIndex;
    }
}

关键突破 ：通过基因嵌入，使相同用户的订单始终落在同一分片，同时支持通过订单ID直接定位分片

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud

• 视频教程：https://doc.iocoder.cn/video/

3 跨分片查询

3.1 异构索引表方案

Elasticsearch索引表结构 ：

{
  "order_index": {
    "mappings": {
      "properties": {
        "order_no": { "type": "keyword" },
        "shard_key": { "type": "integer" },
        "create_time": { "type": "date" }
      }
    }
  }
}

4.2 全局二级索引（GSI）

-- 在ShardingSphere中创建全局索引
CREATE SHARDING GLOBAL INDEX idx_merchant ON orders(merchant_id) 
    BY SHARDING_ALGORITHM(merchant_hash) 
    WITH STORAGE_UNIT(ds_0,ds_1);

4、数据迁移

双写迁移方案 ：

灰度切换步骤 ：

1. 开启双写（新库写失败需回滚旧库）

2. 全量迁移历史数据（采用分页批处理）

3. 增量数据实时校验（校验不一致自动修复）

4. 按用户ID灰度流量切换（从1%到100%）

5、避坑指南

5.1 热点问题

双十一期间发现某网红店铺订单全部分到同一分片。

解决方案：引入复合分片键 (merchant_id + user_id) % 1024

5.2 分布式事务

这里的分布式事务使用的RocketMQ的数据最终一致性方案：

// 最终一致性方案
@Transactional
public void createOrder(Order order) {
   orderDao.insert(order); // 写主库
   rocketMQTemplate.sendAsync("order_create_event", order); // 发消息
}

// 消费者处理
@RocketMQMessageListener(topic = "order_create_event")
public void handleEvent(OrderEvent event) {
   bonusService.addPoints(event.getUserId()); // 异步加积分
   inventoryService.deduct(event.getSkuId()); // 异步扣库存
}

5.3 分页陷阱

跨分片查询页码错乱。

解决方案：改用ES聚合查询或业务折衷方案（只查最近3个月订单）。

6 终极架构方案

性能指标 ：

场景	拆分前	拆分后
用户订单查询	3200ms	68ms
商家订单导出	超时失败	8s完成
全表统计	不可用	1.2s(近似)

总结

1. 分片键选择大于努力 ：基因分片是订单系统的最佳拍档。

2. 扩容预留空间 ：建议初始设计支持2年数据增长。

3. 避免过度设计 ：小表关联查询远比分布式Join高。效

4. 监控驱动优化 ：重点关注分片倾斜率>15%的库。

真正的架构艺术，是在分与合之间找到平衡点。

---

欢迎加入我的知识星球，全面提升技术能力。

👉 加入方式，“长按”或“扫描”下方二维码噢：

星球的内容包括：项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）