TL;DR：在使用增量统计数据时，是否可以找出哪些分区已重新采样，哪些未重新采样？平台为 SQL Server 2014 企业版。
带有一些背景信息的长版本是这样的。
假设一个相当典型的 DW 环境，有一个分区表。分区基于日期列。这是因为将暂存数据加载到单独的表上，并且在预处理之后，使用分区切换将数据移动到生产事实表中。哦，一个聚集列存储索引正在使用中。使用了大约一千个分区。数据库在虚拟机上运行。
事实表中有大约 7.5 gigarows (100 GB)。每日增长约为 5 兆。这个增长率太小，无法触发自动统计更新，保存跟踪标志 2371（尚未尝试）。
开发人员对过时统计数据的下意识反应是更新它们。对于 7.5 gigarows，所有统计数据的完整更新需要大约五个小时。对于单个统计更新，处理性能约为每秒 20 分钟或 90 兆行。
由于系统位于 VM 平台上，因此业务规则限制了其成本。内存和 IOPS 都不容易增加。五小时的更新工作太慢，无法包含在每晚的 ETL 过程中，因此统计数据要么过时，要么在意外的时间更新，要么将在维护窗口中更新。
由于 SQL Server 是 2014 企业版，它支持增量统计，听起来就像解决方案。将统计信息转换为增量统计信息后，处理单个分区的单个统计信息只需 20 秒。新切换的分区总计约五分钟。这听起来很棒，当然也适合 ETL 过程。
我想知道的是如何在分区切换环境中管理增量统计信息。假设统计数据在日期 D 被转换和更新为增量，那么如何找出未处理的分区，例如，日期 D+2？在 ETL 过程中更新统计信息是微不足道的，因为切换过程显然知道分区 ID。但是，如果存在未重新采样的分区，如何找到这些分区？
sys.dm_db_stats_propertiessys.partitionssys.partition_range_values可以选择统计数据的最后更新日期 L 并将其与今天的日期 T 进行比较。然后计算 L 指向哪个分区 id 以及它是否与 T 相同。然后继续更新所有分区 ID [L, T)。这听起来很棘手且容易出错，那么有更好的方法吗？显示哪些分区用于重采样的 DMV 会很好，但没有，是吗？