什么是冷热数据？
你有没有遇到过这种情况：公司用的CRM系统越来越慢，查个客户记录要等好几秒。一问运维，说是数据库太大了，老数据堆在那儿不动，查询全表扫描，能不慢吗？
其实这就是典型的“冷热数据”混在一起的问题。所谓热数据，就是经常被访问、写入的数据，比如最近一周的订单、活跃用户的资料；而冷数据是那些很少被读取的历史数据，比如三年前的交易记录，虽然不能删，但几乎没人翻。
为什么要做分离？
把冷数据和热数据放在一块，就像把当季衣服和过冬棉被全塞进一个衣柜。找件T恤得翻半天，柜子还容易坏。数据库也一样——资源被大量低频数据占用，性能下降，存储成本还高。
通过冷热分离，把高频访问的数据留在高性能存储（比如SSD、Redis），低频的挪到便宜存储（比如对象存储、归档数据库），系统响应快了，服务器开销也降下来了。
怎么判断冷还是热？
不是所有老数据都是“冷”的。关键看访问频率。比如电商的“双11”订单虽然是去年的，但年底对账时可能频繁调用，这时候它就是“阶段性热数据”。可以结合日志分析，统计每类数据的访问频次和时间分布。
一个简单方法是加个访问标记字段：
UPDATE user_log SET last_access = NOW() WHERE user_id = 123;再配合定时任务，把超过90天没访问且非关键业务的数据打上“冷”标签。
实际怎么做？
常见做法是在应用层做路由。比如用户查订单，先判断时间范围：
if (order_date >= '2024-01-01') {
// 查主库（热数据）
} else {
// 查归档库或ES索引（冷数据）
}也可以借助中间件，比如ShardingSphere，配置自动按日期分片，把历史数据路由到不同的物理节点。
还有一种方式是透明归档。MySQL Archive引擎适合存日志类数据，压缩率高，不支持索引，但正好匹配“只查不改”的冷数据场景。
别忽视的一点：冷数据也可能变热
某次运营活动突然要召回五年前的老用户，结果发现数据在磁带库里，恢复要两天。所以冷数据不是“死数据”，归档时得保留可检索性，最好建立轻量级索引，比如把用户ID和归档路径映射存到Elasticsearch里，查起来也不至于抓瞎。
冷热分离不是一次性的技术改造，而是持续的数据治理。定期评估数据热度，动态调整策略，才能让系统一直跑得顺畅。