冷热数据分层透明访问的视图核心逻辑是通过union all显式合并热表与冷表，应用只需查询视图名而无需感知底层存储差异；必须确保查询条件能下推至底层表，否则冷表全量扫描将使分层失效。

什么是冷热数据分层透明访问的视图核心逻辑 视图本身不存储数据，所以“透明访问”不是靠视图自动路由，而是靠在视图定义中显式拼接热表和冷表，并用 UNION ALL 合并结果。关键在于：热表走高频查询路径（如本地 SSD 表），冷表走低成本存储（如归档分区、外部表或跨库表），而应用只需查视图名，无需感知底层拆分。

常见错误是直接用 UNION——它会去重，导致性能暴跌且可能丢数据；必须用 UNION ALL。另外，如果热表和冷表字段顺序或类型不一致，视图创建会失败，或者运行时隐式转换出错。

如何写一个带时间分区判断的冷热视图（以 PostgreSQL 为例） 假设热数据为最近 90 天，存在 orders_hot 表；冷数据存于 orders_cold，按年分区。视图需保证查询条件能下推（尤其时间范围），否则全表扫描冷表就失去意义。

CREATE VIEW orders AS
SELECT id, user_id, amount, created_at, 'hot'::TEXT AS source
FROM orders_hot
WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'
UNION ALL
SELECT id, user_id, amount, created_at, 'cold'::TEXT AS source
FROM orders_cold
WHERE created_at <p>注意点：</p>

• WHERE 条件必须写在每个子查询里，不能只写在最外层——否则优化器无法下推，冷表仍会被全扫
• created_at 字段在两张表中必须是同类型（如都是 TIMESTAMP WITH TIME ZONE），否则视图编译报错
• 加 'hot'/'cold' 标识列方便调试，但生产环境可删

MySQL 中实现类似效果要注意哪些兼容性坑 MySQL 不支持在视图定义中直接用 CURRENT_DATE - INTERVAL 做动态分区裁剪（5.7/8.0 均不支持函数作为视图过滤常量），所以得换思路：

• 方案一：用分区表替代冷热分离，建一个按 created_at RANGE 分区的 orders 表，再让 DBA 手动 ALTER TABLE ... REORGANIZE PARTITION 把旧分区迁到冷存储（如归档实例）
• 方案二：用存储过程+临时表模拟视图行为（不推荐，破坏透明性）
• 方案三：退一步，在应用层控制“查哪个表”，视图仅作字段对齐占位（例如只定义字段结构，不包含 WHERE）

更现实的做法是：在 MySQL 中把视图当作“字段契约”，实际路由交给中间件或 ORM。强行在视图里硬编码日期边界（如 WHERE created_at >= '2024-01-01'）会导致每月要人工 CREATE OR REPLACE VIEW，运维成本高。

为什么 WHERE 条件下推失败会让冷热分层失效 这是最容易被忽略的致命点。即使你写了带 WHERE 的子查询，某些数据库（如早期 Greenplum、部分 Presto 版本）在视图嵌套较深或含函数时，会丢失谓词下推能力。表现是：执行 SELECT * FROM orders WHERE created_at > '2024-06-01'，冷表仍被全量读取。

验证方法很简单：

• 在 PostgreSQL 中用 EXPLAIN 看执行计划，确认 orders_cold 节点是否带 Filter 行且显示具体条件
• 在 MySQL 中看 EXPLAIN FORMAT=TREE，检查是否出现 attached_condition 覆盖冷表
• 如果没有，说明下推失败，要么改写为物化视图（如 PostgreSQL 的 MATERIALIZED VIEW + 定时刷新），要么放弃视图，改用查询路由层

冷热分层真正起效，不取决于视图是否存在，而取决于查询条件能否穿透视图抵达底层表——这点比语法正确性重要十倍。