分区视图必须用 UNION ALL，且所有 SELECT 的列名、数据类型、顺序严格一致；基表需同结构，显式写列名，分区键 WHERE 条件须互斥可推导以支持分区消除。
分区视图必须用 UNION ALL 且所有 SELECT 的列名/类型/顺序严格一致
SQL Server 的分区视图（Partitioned View）不是自动分发查询的智能路由，它本质是手动拼接的 UNION ALL 视图。如果任意一个子查询的列顺序错位、类型隐式不兼容（比如 INT 和 SMALLINT），或列别名不统一，视图创建直接失败，报错类似 All queries in a UNION query must have the same number of expressions in their target lists。
实操建议：
- 所有基表必须有相同结构：同名列、同精度数据类型（宁可显式
CAST也不依赖隐式转换） - 在每个
SELECT中显式写出列名，不用* - 冷热表的分区键（如
created_date）必须出现在WHERE条件中，且条件需“互斥可推导”——SQL Server 靠这个做简单分区消除 - 例如热表查近30天：
WHERE created_date >= DATEADD(day, -30, GETDATE())；冷表查更早：WHERE created_date
冷热表必须建在不同文件组，且分区键要加 CHECK 约束
分区视图能生效的前提，是 SQL Server 能静态判断某行只可能落在某张表里。这依赖每个基表上的 CHECK 约束——没有它，查询优化器无法跳过无关表，全表扫描照旧。
实操建议：
- 热表（如
orders_hot）加约束：ALTER TABLE orders_hot ADD CONSTRAINT chk_hot_date CHECK (created_date >= '2024-01-01') - 冷表（如
orders_cold）加约束：ALTER TABLE orders_cold ADD CONSTRAINT chk_cold_date CHECK (created_date - 两个表必须放在不同文件组（
ON [HOT_FG]/ON [COLD_FG]），否则失去 I/O 分离意义 -
CHECK约束的边界值必须无重叠、无间隙，否则优化器放弃分区消除
查询性能取决于 WHERE 条件能否触发分区消除
即使视图建好了，只要查询没带上能匹配 CHECK 约束的过滤条件，SQL Server 仍会访问全部基表。比如查 SELECT * FROM orders_partitioned_view WHERE status = 'shipped'，没提日期，就全扫。
实操建议：
- 业务查询必须包含分区键（如
created_date）的 SARGable 条件，且格式不能破坏可推导性（避免WHERE DATEDIFF(day, created_date, GETDATE()) ） - 执行计划里看是否出现
Remote Query或实际只访问一张表——这是分区消除生效的标志 - 不要指望视图自动归档：冷数据迁移需手动
INSERT INTO orders_cold SELECT ... FROM orders_hot WHERE ...+DELETE，视图本身不移动数据
SQL Server 2016+ 更推荐用原生表分区，而非分区视图
分区视图是 SQL Server 2000 时代的方案，现在官方已标记为“向后兼容功能”。它不支持索引视图、无法自动滑动窗口、维护成本高（每次增删分区要改视图定义+加约束+搬数据）。
如果你用的是 SQL Server 2016 或更高版本，直接上原生表分区（CREATE PARTITION FUNCTION + SCHEME）更稳。分区视图只在两种场景还值得考虑：升级受限的老系统，或需要跨数据库（甚至跨实例）拼数据——但后者得用链接服务器，延迟和事务一致性都难保障。
冷热分离真正难的从来不是语法，而是 CHECK 边界怎么定、归档脚本怎么防丢失、查询习惯怎么对齐分区键——这些细节一漏，视图就退化成 UNION ALL 性能黑洞。
