冷热数据区分核心在于访问频率、业务状态和时间维度，需结合场景动态定义：热数据（近7–30天+活跃状态）、温数据（30天–1年+已完结）、冷数据（1年以上+终态且禁写），并辅以访问日志校准。
冷热数据的区分核心在于访问频率、业务状态和时间维度，不是靠固定规则，而是结合实际使用场景来定义。
按时间维度判断冷热数据
这是最常用也最直观的方式。比如订单表中，最近30天的数据算热数据，1年前的数据基本就是冷数据。关键是要结合业务周期——电商大促后订单活跃期可能延长到90天，而日志类数据可能7天就转冷。
- 常见阈值参考：热数据（近7–30天）、温数据（30天–1年）、冷数据（1年以上）
- 字段选择：优先用带业务语义的时间字段，如
create_time、order_date、last_update_time - 注意避免仅依赖
create_time：有些历史订单可能因售后被频繁查询，需结合访问日志辅助判断
按业务状态判断冷热数据
很多系统中，数据是否“终态”比时间更重要。一旦进入不可变更的状态，后续只有读取需求，天然适合归为冷数据。
PHP与MySQL程序设计3
下载
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。 本书内容全面深入，适合各层次PHP和MySQL开发人员阅读，既是优秀的学习教程，也可用作参考手册。
- 典型例子：订单状态为
'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）或归档表空间
