数据冷热分离：归档策略、查询路由与平滑迁移

数据是有温度的

业务数据库里，真正被高频读写的往往只有最近 3~6 个月的数据，历史数据占了 80% 的存储却在拖累每一次查询、备份与 DDL。冷热分离的核心逻辑：把「访问频率」变成「存储位置」的函数——热数据留在主库（性能优先），冷数据下沉到廉价存储（成本优先），查询层按需路由。一、冷热的判定标准

1. 时间维度（最常用）：按业务时间划线——订单库保留 6 个月在线，历史进归档库；日志类通常 7~30 天在线；
2. 状态维度：终态数据（已完成订单、已结清账单）天然变冷——按「状态 + 时间」组合判定比纯时间更准；
3. 访问维度：从查询日志统计真实访问分布验证判定线——预估的冷线与实际访问模式经常不一致，用数据说话。

二、归档架构的三个组件

1. 归档任务：定时扫描到期数据（复用分片调度），「先写归档库、校验一致、再删主库」——删除必须有顺序与校验，乱序会丢数据；大批量删除用小批量循环（避免长事务与主从延迟）；
2. 归档存储选型：需要随机查询的历史数据用廉价 MySQL 实例或 TDSQL-C；只做审计/合规留存的用对象存储（按 Parquet/CSV 打包，成本降一个数量级）；
3. 查询路由：应用层路由（DAO 按 时间/状态 分流）或中间件层路由（ShardingSphere 类按条件路由数据源）——路由规则要集中管理，散在各业务代码里的路由条件是维护灾难。

三、迁移期的双读与平滑切换

存量数据首次归档是最大的工程风险，标准做法是双读灰度：新查询逻辑先同时支持主库与归档库（按时间路由，边界数据双查合并），灰度验证正确率后逐步放量。切写侧不动（新数据始终写主库，只有归档任务搬旧数据），风险集中在读路径，回滚容易。

四、四个常见坑

1. 跨库查询：冷热分离后「查全部历史」的需求变成跨库问题——要么走归档库的专用查询接口（异步导出），要么接受离线分析（数仓）承载，别试图在线跨库 JOIN；
2. 边界抖动：刚好压线的数据（6 个月零 1 天）在读与归档的间隙被改——归档删除前再校验一次更新时间，或边界缓冲 7 天再归档；
3. 备份窗口骤变：主库变小后备份策略要同步调整（更频繁的小备份），归档库要有独立的备份与保留策略；
4. 合规与保留期：金融类数据的保留年限有法定要求，删除策略要过合规评审——归档不是删除，删除是有法律后果的动作。

五、验收指标

分离效果看四个数：主库容量降幅（预期 70%+）、热数据查询 P95 变化（预期显著改善）、归档查询可用性（秒级返回或明确告知走异步）、月度存储成本降幅。数字不达预期就回去修判定线与路由规则。

冷热分离的本质是用「数据访问的局部性」换存储与性能的红利。它不是一次性的项目——新表接入时的冷热规划、每季度的访问模式复核，让它成为数据生命周期的常态化管理。