冷热数据区分核心在于访问频率、业务状态和时间维度，需结合场景动态定义：热数据（近7–30天+活跃状态）、温数据（30天–1年+已完结）、冷数据（1年以上+终态且禁写），并辅以访问日志校准。
冷热数据的区分核心在于访问频率、业务状态和时间维度，不是靠固定规则，而是结合实际使用场景来定义。
按时间维度判断冷热数据
这是最常用也最直观的方式。比如订单表中，最近30天的数据算热数据，1年前的数据基本就是冷数据。关键是要结合业务周期——电商大促后订单活跃期可能延长到90天，而日志类数据可能7天就转冷。
- 常见阈值参考：热数据（近7–30天）、温数据（30天–1年）、冷数据（1年以上）
- 字段选择：优先用带业务语义的时间字段，如
create_time、order_date、last_update_time - 注意避免仅依赖
create_time：有些历史订单可能因售后被频繁查询，需结合访问日志辅助判断
按业务状态判断冷热数据
很多系统中，数据是否“终态”比时间更重要。一旦进入不可变更的状态，后续只有读取需求，天然适合归为冷数据。
- 典型例子：订单状态为
'completed'、'closed'、'cancelled'；工单状态为'resolved'或'archived' - 组合条件更稳妥：比如
status = 'completed' AND last_process_time - 重要前提：冷数据必须禁止写入——业务代码或数据库权限层面要确保不会对冷表执行
UPDATE/delete
按访问行为辅助验证
时间与状态是静态规则，真实热度需要动态验证。可通过慢查日志、查询频次统计等手段反向校准冷热边界。
- 用
performance_schema或代理层日志分析高频查询的WHERE条件和主键范围 - 简单sql示例：统计某段时间内被查询最多的订单ID
- select order_id, count(*) AS hit_count FROM information_schema.PROFILING GROUP BY order_id ORDER BY hit_count DESC LIMIT 20;（需开启profiling，生产慎用）
- 若发现大量查询集中在某几个老ID上，说明单纯按时间划分不合理，需调整策略
冷热分层的三层模型（实用参考）
实际落地时，不必只分冷/热两层。引入“温数据”作为缓冲层，能更好平衡性能与运维成本。
- 热层：近30天 + 活跃状态（如
status IN ('pending','processing')），放SSD+高配实例，要求毫秒响应 - 温层：30天–1年 + 已完结但可能用于月报/客服查询，可走从库或降配主库，秒级响应即可
- 冷层：1年以上 + 终态数据，迁出mysql，存入列存数据库（如clickhouse）、对象存储（如OSS+S3 Select）或归档表空间