小编Gok*_*han的帖子

这与在带有嵌套循环的查询之上有一个公共密钥驱动程序有关，并且来自驱动程序的行的并行性是需求类型或循环类型。我会假设需求分区会表现得更好，但我得到了相反的结果。

我在 SQL Server 中的同一次尝试中同时启动了查询。当我监控的查询运行时dm_exec_query_profilesdmv 不断。我注意到循环版本的启动速度要快得多，它们在 dmv 的表插入部分中插入更多行的速度要快得多，而且它们从驱动程序侧并行性部分更快地获取更多行。从逻辑上思考需求分区应该更有利，因为我们的 SQL 服务器通常超过 50-60% 的 cpu，运行 litespeed 备份，有 64 个内核等。我能够通过循环分区更好地平衡线程上处理的行，还有数据分区内是如此不平衡我注意到需求分区中的一些线程仅处理来自驱动程序的 1 条记录，而来自驱动程序的平均记录大约为 196。通过需求分区，我对分区内的行进行降序排序，而在循环中我尝试更好地平衡行。

我是否应该始终使用循环法，为什么循环法开始处理行的速度比需求分区快得多，我可以对需求分区进行更多优化吗？

查询计划位于 One Drive 链接中，我找不到在此处发布它们的另一种方式（pastetheplan 仅接受 xml，它不捕获计划资源管理器捕获的等待统计信息和持续时间等额外信息）。

CompareRoundRobinToDemand_DM_2_5114.pesession CompareRoundRobinToDemand_RRB_2_3046.pesession

同时开始，Round Robin 的速度要快得多

CompareRoundRobinToDemand_DM_3_5228.pesession CompareRoundRobinToDemand_RRB_3_4367.pesession

同时开始，Round Robin 又快了

CompareRoundRobinToDemand_DM_4_4813.pesession CompareRoundRobinToDemand_RRB_4_3577.pesession

同时开始，Round Robin 又快了

先感谢您。

查询计划

我能够平衡几乎完美的循环行，而对于需求，我只是按行降序排列驱动程序，平衡需求中的行是我的程序中的一个选项，但没有产生更好的结果。在我的观察中，当整体 CPU 使用率较低时，需求表现更好，而当服务器更忙时，轮询表现更好。我注意到与循环相比，需求创建了一个额外的线程，而且总体 CPU 利用率需求略高于类似的 RRB 版本。

我知道需求中的行分布不平衡。内存授予也是故意的，它最终没有使用那么多内存。从驱动程序传递的前 16 条记录的需求与循环法相同，但循环法由于某种原因开始处理它们的速度要快得多。我想明白为什么。我还想了解什么时候使用需求或循环法更有利。似乎当服务器空闲时需求工作得更快，当服务器有现有负载时循环更快，这是迄今为止的观察，这是否有我不知道的基础。

我们正在运行SQL Server 2014 Enterprise Sp2使用1.5TB的内存和64 cores。17 GB这个单线程查询的内存接近，使用的最大内存是2.2gb，即使散列连接有足够的可用内存，它似乎没有使用它并溢出到磁盘。知道为什么吗？先感谢您。

SQLPerformance 中发布的相同问题。查询计划和图像张贴在那里

我想了解内存分数。它显示哈希连接具有 52.48% 的内存授权（总计 17GB+），接近 9GB。但是该计划使用的最大内存要少得多，即 2.2+GB，并且 Hash join 是此查询中唯一的溢出。我对内存分数有什么遗漏，它们不准确吗？

SQL Server 版本是 2014 Developer SP1。跟踪标志272, 610, 1118, 1206, 1222, 8048, 9481是全局打开的。

我们不得不打开标志 9481，因为新的基数估计器严重影响了许多查询计划。查询没有排序、散列或并行。当我运行查询时，几分钟内没有返回结果。

在执行期间，sys.dm_exec_query_memory_grants dmv 还报告了超过 1.3TB 的理想内存。(WhyGiganticDesiredMemory.queryanalysis)

我运行了一个非常相似的查询。在 ActualPlan.queryanalysis 中所需的内存为 124GB，授予为 44GB，而在 ActualPlanWithLessMemoryGrant.queryanalysis 中所需的内存仅为 10MB。

它们之间的唯一区别是从后者中删除的嵌套循环下方的最左侧索引查找（我在连接条件中添加了一个无效过滤器 1 = 0 以从计划中删除该表）。

我的查询如下所示：

SELECT  CAST('C' AS CHAR(1)) AS [Action]
      , f.LoadId
      , u.UnvPclId
      , p.*    --- [about 480 columns, Daniel Hutmacher's edit]
FROM    [tExtract].[ExtractCounty] f
INNER JOIN [tControl].[VersionControl] vc ON Id = 1
INNER JOIN [tTax].[Property] pk WITH ( NOLOCK, FORCESEEK ( UpdateVersion_CntyCd ( UpdateVersion ) ) ) …