冷热数据联合查询的视图实现本质是通过显式union all将冷热表逻辑合并，依赖数据库优化器对where条件的谓词下推能力实现透明路由，而非自动分区裁剪；必须带冷热区分条件（如时间范围），否则全表扫描。
什么是冷热数据联合查询的视图实现本质
视图本身不存储数据，它只是保存一条 SELECT 语句。所谓“透明化联合查询”，核心是让应用层无需感知冷表（如 orders_history）和热表（如 orders_current）的物理分离，只查一个视图名就能自动路由到对应分区——这靠的是视图定义中显式 UNION ALL + 合理的谓词下推能力。
必须用 UNION ALL 而不是 UNION
UNION 会触发去重排序，对大表（尤其历史冷表）性能杀伤极大；而冷热数据天然互斥（比如按 created_at 划分），用 <code>UNION ALL 才能避免无谓开销。
常见错误：写成 UNION 后发现查询变慢几倍，执行计划里出现 Sort 和 Unique 节点。
实操建议：
- 冷热分界条件必须明确且稳定（推荐用日期字段，避免用业务状态码这类易变维度）
- 两个子查询的列顺序、类型、数量必须严格一致，否则建视图失败
- 在热表上建好
WHERE created_at >= '2024-01-01'索引，在冷表上建好对应范围索引，否则谓词无法下推，全表扫描不可避免
如何让 WHERE 条件真正下推到子查询
视图不是魔法，WHERE 是否能下推取决于数据库优化器。PostgreSQL 和 MySQL 8.0+ 支持较充分，但 SQL Server 需要 SCHEMABINDING + 确保子查询不含不可下推结构（如子查询、窗口函数、GROUP BY）。
典型失效场景：
- 视图定义里用了
COALESCE(status, 'unknown')，外部WHERE status = 'paid'就无法下推到基表 - 冷表子查询里写了
LEFT JOIN，而外部条件在右表字段上，多数引擎不会下推 - MySQL 5.7 不支持对视图的
WHERE下推，升级到 8.0+ 是硬性前提
验证方式：执行 EXPLAIN SELECT * FROM order_view WHERE created_at > '2024-06-01';，看是否只扫描热表（orders_current）的索引范围。
为什么不能依赖视图自动分区裁剪
即使你把冷热逻辑写进视图，数据库也不会像原生分区表那样自动做分区裁剪。视图里的两个 SELECT 是静态并列关系，优化器只能靠谓词分析来跳过某个分支——这意味着：没有合适的 WHERE 条件，就会两个表都扫。
所以关键约束是：所有对视图的查询，必须带上能区分冷热的过滤条件（通常是时间范围）。如果业务存在大量无条件查询（如后台导出全量），这个视图就不适用，得另配全量物化视图或定时合并表。
容易被忽略的一点：应用层 ORM 可能自动生成无条件 SELECT *，或者带 OFFSET/LIMIT 但没 WHERE，这种调用会直接暴露性能问题。
