订单表 2 亿行，但 90% 的查询只用到近 3 个月的数据。冷热分离让数据库轻装上阵。

一、冷热分离的核心理念

  • 1.1 热数据——频繁访问的近期的数据
  • 1.2 冷数据——很少访问的历史数据
  • 1.3 时间维度 vs 状态维度
  • 1.4 目标——热库保持小体积高性能

二、方案 1：同库分区

  • 2.1 MySQL 分区表——PARTITION BY RANGE (TO_DAYS(create_time))
  • 2.2 优点——应用层无感知
  • 2.3 缺点——单库压力仍在

三、方案 2：冷热分表

  • 3.1 热表——order_2025（当前年）
  • 3.2 冷表——order_2024、order_2023
  • 3.3 按年/月动态创建表
  • 3.4 查询路由——时间范围选择表

四、方案 3：异构存储

  • 4.1 热数据在 MySQL
  • 4.2 冷数据在 Hive / HBase / TiDB
  • 4.3 定时归档任务——每天凌晨迁移
  • 4.4 查询时需要先查热库再查冷库

五、数据迁移策略

  • 5.1 定时任务——delete + insert，有风险
  • 5.2 软删除——标记状态，异步迁移
  • 5.3 双写——同时写热库和冷库

六、归档查询的设计

  • 6.1 管理后台查历史数据——独立查询接口
  • 6.2 用户端查自己的历史——限制时间范围
  • 6.3 冷热查询的统一 API 封装

七、总结

  • 冷热分离是数据量增长后的必然选择
  • 先分区再分表，最后才考虑异构存储