3

我们有一个包含超过 100.000.000 条记录的表，它是一个缓慢变化的维度，对于相同的持久键，字段 ValidFrom（在下面的屏幕截图中表示为 TaskDate）和 ValidUntil 决定记录在某个日期的有效性。

在尝试使用过滤索引、过滤统计信息、硬编码参数、动态 SQL 解决问题后......在一个特定问题上没有取得任何进展：优化器选择正确的索引，进行搜索，估计记录相对接近实际记录，但只有一个 CPU 线程读取某些内容。

棘手的阅读 - 倾斜的工作量

不管我是用 MAXDOP 6 运行它，还是让它在所有可用的 CPU 上运行都没有关系。

我还能尝试什么？

第一次编辑：

一些评论集中在所涉及的数据大小上，而这不是问题所在。附加的是向上范围查询，它不仅仅是记录计数（最初用于演示惰性工作线程情况）。

这个惰性工作线程在读取时的直接后果是执行完全相同的键查找 - 只有一个线程正在接收记录并且有事情要做。

执行计划可以看这里： http: //pastebin.com/zJwZ56vh

30 个懒惰线程，其中一个正在工作

4

1 回答 1

2

这在这里解释。并行嵌套循环加入。

您只有一行馈入嵌套循环连接。嵌套循环连接的并行性通常通过在多个线程之间分配外部行来工作，而不是通过让多个线程处理单个外部行。

由于只有一个外部行要处理，这意味着一个线程被分配并最终在该并行区域中完成所有工作（直到重新分区流操作员）

例外

在极少数情况下，单个外部行且没有相关参数可能会在嵌套循环连接的内侧产生并行性

（来源第 21 页）

在您的情况下，您没有交叉连接，并且 from 的值Table3是相关的，并显示在嵌套循环运算符的“外部引用”中，因此不适用异常。

因此，您需要移动要并行化的部分，使其不再位于嵌套循环的内部。如果总是有一行来自Table3您，则可以在单独的查询中将值分配给标量变量，然后在主查询中使用标量变量。

否则，您可以考虑以不同的方式表达查询或使用查询提示来实现此目的。

计划平行部分截图供参考

计划

于 2013-06-27T13:46:25.563 回答