数据库三年涨到几个T，查询越来越慢？数据归档三种方案对比

业务系统跑上几年，几乎都会撞上同一堵墙：订单表、日志表、流水表数据量奔着几亿条去了，备份一次大半天，加索引要锁表，明明只查最近的数据，查询却越来越慢。想删数据，财务说要留七年；想留着，数据库眼看着要撑不住。

核心矛盾是：数据的访问频率随时间断崖式下降，但存储成本不分新旧一刀切。 最近三个月的数据撑起 95% 的查询，三年前的数据一年碰不了一次，却占着最贵的在线存储。冷热分离就是把这个错配纠正过来，主流有三条路线：应用层分表归档、数据库原生分区、独立归档库加对象存储。

方案一：应用层分表归档

原理： 不依赖数据库特性，在应用代码或中间件层面做拆分：热表只留近期数据，定时任务把到期数据搬迁到归档表（同库或异库），查询时按时间路由。分库分表中间件（ShardingSphere 等）天然支持这套玩法。

优点：

• 不挑数据库，MySQL、PostgreSQL 都能用
• 路由逻辑自己掌控，跨表查询、联合查询都能定制
• 归档表可以扔到低配实例上，成本立竿见影

缺点：

• 应用层复杂度上来了：路由、跨冷热查询、归档任务都要自己维护
• 搬迁过程要处理增量数据的一致性，写不好的定时任务会丢数据
• 历史遗留系统改造成本高，查询入口多的话处处要改

适用场景： 已经在用分库分表中间件、或者表结构简单的系统。归档逻辑明确（比如纯按时间）的场景，这是最可控的路线。

方案二：数据库原生分区

原理： 利用数据库的分区表能力（MySQL Partitioning、PostgreSQL declarative partition），按时间分区，历史分区直接 detach 归档或转储，热分区保持小巧。对应用透明，查询还是一张表。

优点：

• 应用几乎零改造，SQL 该怎么写还怎么写
• 分区裁剪自动生效，查近期数据不扫历史分区
• 归档就是 detach 分区，瞬间完成，不用逐行搬迁

缺点：

• 冷热数据还在同一个实例里，存储成本降得有限
• 分区数量有限制，跨分区查询性能反而下降
• 主键、唯一索引要包含分区键，老表改造有约束

适用场景： 查询模式高度按时间过滤、不想动应用代码的系统。日志类、流水类大表是最佳拍档。想靠它大幅降存储成本的会失望，它主要解决的是查询和运维效率。

方案三：独立归档库 + 对象存储

原理： 热数据留在线库，冷数据通过数据管道（CDC 或定时 ETL）归档到独立的分析型存储（ClickHouse、Doris）或直接压缩进对象存储（COS、S3），需要查历史时走归档查询入口，常配合统一查询层对应用屏蔽差异。

优点：

• 成本降得最狠：对象存储的价格是块存储的一个零头
• 在线库彻底瘦身，备份、扩容、维护都轻快
• 归档数据进分析型引擎，历史数据的统计报表反而更快

缺点：

• 架构最重：管道、归档校验、查询入口一整套都要建设
• 冷热联合查询麻烦，跨库 UNION 要么靠查询层要么靠应用拼
• 归档是单向的，冷数据回流在线库要有预案（比如旧订单售后）

适用场景： 数据量大（TB 级以上）、冷数据访问极少、对成本敏感的系统。流水、日志、行为数据这类"写一次读稀有"的数据是天然用户。

按数据特征对号入座

实际项目里经常组合使用：在线库用分区表保持轻快，超过一年的分区 detach 出来进对象存储。热、温、冷三级各得其所。

落地前必做的三件事

第一件：先定保留策略再谈技术方案。 各类数据留多久、什么粒度的查询要支持、合规要求几年，这些要业务、财务、法务签字确认。技术上什么都能存，问题是谁来为"留多久"拍板。策略没定就开工，最后必然变成"什么都不敢删"。

第二件：归档任务必须可校验、可补偿。 搬迁前后做行数和 checksum 比对，归档失败要能重跑。丢一条三年前的订单当时没人发现，发现的时候就是事故。

第三件：给冷数据留查询入口。 归档不等于封存：财务审计、客户查历史订单、监管调阅，这些需求一定会来。哪怕是个内部查询工具，也要在归档方案里预留，别把冷数据归档成"死数据"。

写在最后

冷热分离的本质是按访问频率给数据安排不同价位的"住处"，技术选型反而是后半场。真正决定成败的是三件事：保留策略谁拍板、搬迁过程怎么校验、冷数据怎么查。这三件事想清楚了，不管选哪条路线都翻不了车。