对分区表的低效查询

Question

考虑一下Server中包含有超过500个分区的分区表的场景。临时表中分区列值的数目小于10。我们将临时表直接连接到分区列上的分区表。(不使用$PARTITION，只使用纯列值。)该查询以典型的星型模式类型的方式包含到其他维度表的联接。

此外，表中没有非聚集索引.集群PK中的前导列(忽略始终处于前导的分区键id )是一个连接到星型模式维度表之一的列，它将包括一个过滤器。但是，如果存在索引，如果分区只是一个表，维度表上的筛选器就不会有足够的选择性来导致索引查找。

那么，鉴于以上所述，为什么这个分区表上的查询不总是使用分区消除？什么时候扫描分区表比只扫描所需的分区更有效？

在最坏的情况下，有一个分区的分区表将是相同的，忽略了确定分区消除的成本等等。

Answer 1

好吧，在设法多花点时间看这个问题之后，我发现了这个问题。很明显，但它总是在事后。

因此，当您将文字指定为分区列上的筛选器时，分区消除就会发生。例如：WHERE partition_column = 20150812。凉爽的。

但是，如果您可能需要对多个日期进行筛选，怎么办？也许你想找出任意两天的数据之间的区别，或者把它们加起来什么的。假设这组日期将通过一些输入在运行时提供。此时，如果不使用动态SQL，就不能硬编码WHERE子句中的值。

现在，如果将值放入临时表，并对分区列上的分区表执行内部连接，则Server不再直接显示要在其上筛选的分区，而似乎返回到表扫描。在大桌子上这是个大问题。我确信，SQL Server在使用联接中的分区列进行筛选时，似乎没有延迟绑定或延迟分区消除的概念。

因此，在这种情况下，我不能说我找到了任何一篇文章来描述关于分区表的良好PK的最佳实践。我们迄今所经历的进程是：

1. 使用联接中的$PARTITION函数可以强制Server使用包含该分区值的分区。但是，使用它本身是不正确的，因为它将从包含该值的任何分区返回数据，即使该值不存在。
2. 使用上面的函数以及联接中的分区列来强制后期分区消除，并确保您得到了正确的数据。然而，这有一个严重的副作用。这样做会导致优化器获取分区中的行数，并将其除以分区数，从而产生不正确的行计数。不幸的是，这意味着，除其他外，并行执行计划常常变成串行的，并且被认为大大增加了分区上的并行计划的执行时间。
3. 最近的一次“修复”尝试是将分区列作为PK中的领先列，这似乎是可行的。然而，我们还没有评估低基数领先列的负面影响。我怀疑我们可能需要在下一列(以前是前面的列)上手动创建统计数据，或者等待AUTO STATS为我们做这件事，但确定这是否足够。

Answer 2

这取决于查询，因此，如果您有特定的问题，您需要提供查询的详细信息(可能还有表结构)，以便获得特定的帮助。

不过，一般来说：

• 如果过滤器不是sargable，那么它对查询计划器的帮助就和引用子句不可使用的索引一样--例如，如果涉及到一个不能简化为所有可能行的单个值的函数或子库。
• 如果非分区(或未对齐)索引覆盖的列上有其他筛选器，查询规划器可能会考虑以这种方式进行搜索，比使用分区规则更有效。