分区视图在SQL Server 2019中不推荐用于性能优化，因其无法支持分区消除、并行扫描和批模式执行，而原生分区表配合对齐索引与及时统计信息更新才能真正提升大表查询性能。
分区视图（Partitioned View）在 SQL Server 2019 中**不推荐用于性能优化**，它已被弃用多年，且无法享受现代分区表的执行计划优化能力。真正能提升大表查询速度的是原生分区表（PARTITIONED TABLE），不是 UNION ALL 视图。
为什么分区视图在 SQL Server 2019 中基本失效
分区视图依赖手动建多个结构一致的表 + UNION ALL + CHECK 约束，SQL Server 仅在极有限条件下才做“分区消除”——比如查询谓词必须严格匹配 CHECK 约束边界、且不能有函数包装（如 YEAR(核算年)）、不能涉及参数化或变量。实际业务查询中稍一变形（例如加个 ISNULL 或隐式转换），整个视图就会退化为全表扫描三张表。
更关键的是：SQL Server 2019 的查询优化器**不会为分区视图生成并行分区扫描计划**，也不会利用批模式执行（Batch Mode on Rowstore），而这些是原生分区表能获得性能跃升的核心机制。
- 分区视图不支持对齐索引（Aligned Index），索引无法按分区物理分布
-
INSERT/UPDATE/DELETE语句无法自动路由到目标分区表，需显式写入，极易出错 - 统计信息是按单表维护的，优化器难以准确估算跨表
UNION ALL后的行数，常导致低效连接顺序
应该用原生分区表替代，且必须对齐索引
原生分区表由 PARTITION FUNCTION + PARTITION SCHEME 驱动，SQL Server 能在执行计划中明确标记 PartitionID 扫描范围，并支持自动分区消除、并行分区扫描、批模式执行（即使没有列存储）。
但前提是：所有索引（包括聚集索引）必须使用相同分区列，并通过 ON psDateRange(分区列) 显式指定方案——否则就变成“伪分区”，查询时仍扫全表。
- 分区列建议选高频过滤字段（如
OrderDate、AccountYear），且类型稳定（避免varchar(max)或计算列未持久化） - 创建分区函数时注意
RANGE LEFT和RANGE RIGHT对边界值归属的影响，错误会导致数据错分 - 文件组分配要真实分离（如
FG_2022,FG_2023），若全写PRIMARY，物理上仍是单盘，I/O 无改善
分区后必须定期更新统计信息，否则计划会劣化
分区表的数据倾斜比普通表更明显——新分区数据密集，旧分区可能归档为空。默认自动更新统计信息（AUTO_UPDATE_STATISTICS）只在修改行数超阈值时触发，而冷分区长期无写入，统计信息就一直过期。
结果是：查 2024 年数据时，优化器误以为 2020 分区也有大量数据，生成含多余分区扫描的计划，性能反而下降。
- 对大分区表，应禁用默认自动更新，改用
UPDATE STATISTICS 表名 WITH FULLSCAN, NORECOMPUTE定期全量更新 - 或用
sp_updatestats+WHERE过滤只更新活跃分区（需配合sys.dm_db_partition_stats判断） - 避免在 OLTP 高峰期执行，
FULLSCAN会阻塞 DML
真正的性能瓶颈往往不在“是否分区”，而在分区列选择是否匹配查询模式、索引是否对齐、统计信息是否新鲜——这三者缺一不可。用错分区视图，不如先加好索引+更新统计信息。
