分层这事儿跟温度没半毛钱关系。冷热温数据这套叫法听着像气象，落到机房里其实就一句话：这堆数据最近被访问得多不多，访问的人等不等得起，放久了还要不要拿回来。三个问题一问，热温冷自己就排好队了。按创建时间、按文件大小、按“我感觉它很重要”来分层，十有八九要返工。
冷热温数据，分层看的是访问频次
热数据不是“新数据”。一张三年前的商品图，天天有人点，它就是热的；昨天刚生成的报表，除了归档脚本没人碰，它也热不起来。所以第一指标是访问频次，第二是访问延迟要求，第三是取回成本。把这三个排一下，比看文件年龄靠谱得多。数据库里的热数据通常扛着在线查询，缓存和 SSD 是给它用的；温数据偶尔被翻，标准对象存储或者普通云盘就够；冷数据几个月不动，但法规或业务要求留着，就往归档层放。
先别按“年龄”排，先看谁在访问
访问日志里能看出很多东西。用户请求、后台任务、备份扫描、监控拉取，这四种流量混在一起，很容易把冷数据误判成热数据。比如备份程序每天把整个目录读一遍，监控上看着访问量很漂亮，实际前台根本没几个人看。把来源拆开，热数据一下就瘦了。另一个容易漏的是读放大：一次页面请求背后可能是几十次数据库查询，你看的是页面访问量，掏钱的是数据库 IO。
热层不是越贵越好，命中率才是命门
热层常见的做法是内存缓存加 SSD，数据库前面再挂一层。但缓存不是摆上去就完了，命中率低的时候，请求全打到后面，SSD 再快也顶不住。看两个数：缓存命中率和慢查询占比。命中率上不去，先查 key 设计、过期策略和缓存穿透，而不是急着升配置。热数据放错地方，用户感受最直接，页面转圈、接口超时，通常都从这儿开始。
温层最容易被忽略，也最能省钱
很多业务只有热和冷两个档，中间那层空的。结果就是热层塞不下的一股脑丢冷层，读取延迟一上来，客服电话也跟着来。温层的意义是接住“不常看但随时可能要”的数据，比如历史订单、几个月前的日志、用户上传的旧附件。它不需要极低延迟，但取回得方便，价格也比热层低。实际做法是先设生命周期规则，让数据从热到温自动走一遍，观察一段时间再往下沉。
冷层要算“取回账”，不是只看存储单价
冷存储单价低，但取回可能要按量计费，还有解冻等待时间。有人只盯着每 GB 多少钱，结果月底一算，取回费用比省下来的还多。这里的具体价格和免费额度，不同服务商差得远，以服务商或官方页面说明为准。冷层适合放什么：备份副本、合规留存、很少回查的历史流水。放之前问一句，这东西一年会取回几次，取回时业务能不能等。等不起，就别往最冷的那层塞。
分层落地，先做监控再做规则
顺序别搞反。先跑一段时间的访问统计，按目录、按表、按接口看频次和延迟要求，再定分层线。规则可以从宽到严，先挪最明确的那批，比如超过半年没被前台读过的日志。数据库的冷热分离更要小心，索引、外键、查询路径都得跟着改，别只把表挪走就完事。迁移完做校验，抽样比对行数和校验和，权限也要重新过一遍，别让归档目录变成谁都能读的敞口。
还有个常见毛病，是分层之后监控没跟着改。数据沉下去了，告警还按原来的阈值报，半夜被叫起来查一圈，发现只是备份任务在跑。分层不是搬完文件就结束，访问路径、权限和告警阈值都得同步调。访问控制这块要跟分层一起设计，谁能读、读多久、读一次留什么日志，提前定好，省得冷数据没人看也没人管，最后成了泄露入口。小站数据量不大，也别为了分层而分层，先看账单和慢查询，哪里疼治哪里。
回到最开始那句，冷热温数据看的是访问频次，不是温度，也不是年龄。先翻一周的访问日志，把用户请求和后台任务分开，再拿延迟要求和取回成本排个序，能落地的分层方案基本就出来了。别一上来就买最贵的盘，也别把“以后可能要用”当成热数据的理由。先挪一批，跑稳了再挪下一批。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
