什么是冷热数据？
在日常工作中，你可能已经接触过冷热数据的概念。比如你在公司用的报表系统，最近三个月的数据经常被查询，响应要快；而三年前的历史订单几乎没人翻，但又不能删。这些“常用”的就是热数据，“不常碰”的就是冷数据。
为什么要分离？
想象一下，你把家里所有衣服——夏天的T恤、冬天的羽绒服、去年穿过的袜子、十年前的校服——全都塞在一个小衣柜里。每次找衣服都得翻半天，柜门还关不上。这就是没做分类的后果。
数据也一样。如果把高频访问的热数据和多年不动的冷数据混在一起存，数据库压力大，查询变慢，成本也高。尤其是当数据量达到TB甚至PB级时，这种问题会越来越明显。
怎么分？按时间和使用频率来划线
最常见的划分方式是按时间。比如电商系统中，把过去90天内的订单当作热数据，存在高性能的SSD存储或内存数据库里；超过90天的自动归为冷数据，转存到便宜的机械硬盘或者对象存储中。
也可以结合访问频率。比如用户行为日志，某些热门页面的日志频繁被分析，就保留在热区；其他低频访问的迁走。这种动态判断可以靠后台任务定期扫描访问记录来实现。
一个简单的标记示例
<?php
// 伪代码：判断是否为热数据
$lastAccessTime = getDataLastAccess($recordId);
$cutoffTime = strtotime('-90 days');
if ($lastAccessTime > $cutoffTime) {
moveToHotStorage($record);
} else {
moveToColdStorage($record);
}
?>存储方案怎么选？
热数据讲究“快”。可以用Redis缓存热点记录，或者用Elasticsearch支撑实时查询。这类系统响应快，但价格贵，不适合全量存。
冷数据追求“省”。像阿里云OSS、AWS S3这类对象存储，每GB成本只有数据库的几十分之一，虽然读取慢一点，但胜在便宜耐用，适合长期归档。
自动流转机制不能少
手动挪数据不现实。通常会写个定时任务，每天凌晨跑一次，检查哪些数据该降温了。比如银行交易系统，每月初把上个月的数据从在线库归档到数据仓库。
更智能的做法是加入访问热度监控。某个冷数据突然又被频繁查，系统能自动把它提回热区，就像冰箱里的冷冻食品临时要用了，先放进冷藏室解冻。
实际场景：某电商平台的优化案例
这家平台原来所有订单都在一个MySQL集群里，随着数据增长，订单查询越来越卡。后来他们做了分离：最近一年的数据留主库，之前的数据迁到ClickHouse集群。
用户查自己的订单，默认只拉最近一年，走高性能查询；真要点开“历史订单”才去冷库存调。结果主库负载降了60%，服务器没加一台，查询速度反而提升了。
别忘了数据一致性
分离之后，两个系统之间要有同步机制。可以用消息队列（如Kafka）记录数据状态变更，确保冷热切换时不丢不重。同时对外提供统一接口，让应用层感觉不到背后有两套存储。
比如API网关根据请求参数判断是否涉及历史数据，再决定打向哪个后端。这样业务代码不用改，运维也轻松。