冷热数据分层是围绕访问频率、更新频率、业务SLA和存储成本的系统性权衡，核心是热数据快稳易查、冷数据省安可溯；需多维识别热数据，采用混合架构分层存储，并协同SQL优化、归档治理与动态迭代。
冷热数据分层不是简单按时间切表，而是围绕访问频率、更新频率、业务SLA和存储成本做系统性权衡。核心是让热数据快、稳、易查，冷数据省、安、可溯。
识别热数据的关键维度
不能只看“最近3个月”，要结合多维信号交叉判断：
- 查询频次：通过慢日志或代理层统计，高频WHERE条件字段（如order_status=‘paid’、user_type=‘vip’）涉及的数据往往持续活跃
- 更新密度：订单表中“已支付→已发货→已完成”状态链路的数据，在履约周期内属于强热区；一旦完成超7天且无售后工单，大概率转冷
- 业务强依赖：风控实时拦截、推荐实时特征、客服会话上下文等场景所依赖的表/分区，即使体量小也应保留在热层
分层存储的落地组合方式
单一引擎难兼顾所有需求，推荐混合架构，按需组合：
- 热层（毫秒级响应）：MySQL主实例 + Redis缓存热点行；对高并发点查场景，用Redis Hash结构缓存用户profile、商品库存等聚合态数据
- 温层（秒级响应）：MySQL归档库（独立实例）+ 按月/按业务域分区；用pt-archiver定期迁移，保留完整索引但关闭binlog压缩以降低IO压力
- 冷层（分钟级可查）：对象存储（如S3/OSS）+ Parquet格式 + Trino/Presto即席查询；历史订单、日志类数据转为列存，配合分区字段（dt、biz_type）加速过滤
SQL写法与分层策略协同优化
再好的分层，也扛不住错误的SQL透传。必须在应用层做隔离控制：
- 所有查询强制走路由中间件（如ShardingSphere、MyCat），根据SQL中的时间范围、状态码、租户ID自动打标并路由到对应层级
- 禁止跨层JOIN：热表join冷表需提前物化——例如每日凌晨将前一日订单关联用户标签结果预计算到温层宽表
- 冷数据查询加显式提示：在SELECT后追加/* cold_query */，由代理层限流、降级或拒绝执行未授权的全量扫描
冷数据归档与生命周期管理
归档不是“删完就完”，而是可验证、可回溯、可审计的过程：
- 归档前校验一致性：对比源表COUNT(*)与目标Parquet文件行数，再抽样1000条主键做MD5比对
- 保留元数据映射表：在热库中建archive_meta表，记录每批归档的起止时间、数据量、文件路径、校验哈希，便于问题定位
- 设置分级保留策略：6个月内冷数据支持即时查询；6–24个月仅开放按主键/时间范围导出；超2年加密压缩后离线保存，需审批解密
基本上就这些。分层不是一锤子买卖，需要每季度回顾访问模式变化，动态调整热区边界和归档节奏。不复杂但容易忽略的是——把分层逻辑真正下沉到DAO层和SQL模板里，而不是靠DBA手工搬数据。
