10亿订单如何做分库分表？ - 文章 - 开发者社区

大家好，我是苏三，又跟大家见面了。

前言

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

  
-- 简单查询竟需12秒！  
SELECT * FROM orders WHERE user\_id=10086 LIMIT 10;  
  
-- 统计全表耗时278秒  
SELECT COUNT(*) FROM orders;

核心矛盾 ：

B+树索引深度达到5层，磁盘IO暴增。
单表超200GB导致备份时间窗突破6小时。
写并发量达8000QPS，主从延迟高达15分钟。

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

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

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

1 分库分表核心策略

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

picture.image

优化效果 ：

核心表体积减少60%
高频查询字段集中提升缓存命中率

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

分片键选择三原则 ：

离散性 ：避免数据热点（如user_id优于status）
业务相关性 ：80%查询需携带该字段
稳定性 ：值不随业务变更（避免使用手机号）

分片策略对比 ：

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

2 基因分片

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

用户查历史订单（user_id）
商家查订单（merchant_id）
客服按订单号查询（order_no）

解决方案 ：

picture.image

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直接定位分片

3 跨分片查询

3.1 异构索引表方案

picture.image

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、数据迁移

双写迁移方案 ：

picture.image

灰度切换步骤 ：

开启双写（新库写失败需回滚旧库）
全量迁移历史数据（采用分页批处理）
增量数据实时校验（校验不一致自动修复）
按用户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()); // 异步扣库存  
}