SQL数据冷热分层是基于访问频次、更新状态和业务SLA对数据生命周期的结构化管理，实现热数据快、温数据稳、冷数据省，并通过视图路由、分区降级、联邦查询等技术保障SQL透明性。
SQL 数据冷热分层不是简单地“把旧数据挪走”，而是基于访问频率、业务时效性与成本效益，对数据生命周期做结构化管理。核心目标是：热数据快、温数据稳、冷数据省。
什么是冷热分层？关键看三个维度
判断一条数据该归入哪一层，主要看：
- 访问频次：近7天订单表每秒被查上百次 → 热；3年前日志表半年只被审计查1次 → 冷
- 更新状态：用户账户余额表持续写入 → 热；历史账单表插入后永不更新 → 冷
- 业务SLA要求：实时风控需毫秒响应 → 必须热存；合规归档要求可接受分钟级查询 → 可入冷层
典型多级存储结构（4层落地示例）
实际中常见分层并非固定三级，而是按技术栈和成本弹性组合。一个兼顾性能与运维的四层结构如下：
- 热层（Hot）：内存+SSD缓存 + 主库（如 PostgreSQL / MySQL 高配实例），存放最近24–72小时高频读写数据，索引全开，支持事务强一致
- 温层（Warm）：高性能云盘或列存数据库（如 ClickHouse / Doris），存最近3–6个月活跃但非实时数据，按天/周分区，支持亚秒级分析查询
- 冷层（Cold）：对象存储（如 S3 / OSS）+ 数据湖格式（Parquet/ORC），配合 Trino/Presto 查询，存6个月以上只读数据，压缩率高、成本低，查询延迟几秒到几十秒
- 归档层（Archive）：低成本冷备介质（如 Glacier / 归档NAS），仅用于法规留存，恢复需数小时，一般不直接对接SQL引擎，需解冻后导入冷层再查
SQL层面如何支撑分层？重点在路由与透明性
应用不应感知数据在哪一层。可通过以下方式实现逻辑统一、物理分离：
- 视图路由：建统一视图（如 v_user_behavior），底层用 UNION ALL 合并热表（user_behavior_recent）与冷表（user_behavior_historical），配合 WHERE 条件下推自动剪枝
- 分区表自动降级：在支持时间分区的引擎（如 TiDB、StarRocks）中，将表按天分区，并配置策略：30天前分区自动转存至冷存储，查询时由执行引擎自动调度
- 联邦查询网关：用 Apache Doris 或 StarRocks 的外表功能，把 S3 上的 Parquet 文件映射为本地表，SQL不变，执行时跨源拉取，对业务无感
必须避开的几个设计坑
分层失败往往不是技术不行，而是忽略了协同细节：
- 没定义清楚冷热切换的触发条件（比如是按时间？还是按访问次数衰减？），导致数据滞留热层抬高成本
- 冷层数据缺少必要元信息（如业务主键、分区字段语义），后续无法关联或过滤，变成“能存不能查”
- 忽略一致性保障：热层更新后未及时同步到温层（如用 Flink CDC 做双写），出现“刚下的单查不到”问题
- 权限体系没对齐：DBA 给了热库 SELECT 权，但忘了给冷层 S3 Bucket 的读权限，SQL报错才暴露
基本上就这些。冷热分层不是一次配置完就一劳永逸的事，需要配合监控（如各层QPS、延迟、存储占比）、定期评估（每月看热区是否过载、冷区是否有误入的热数据），才能真正跑起来。
