小编use*_*507的帖子

我有一个长时间运行的查询（有 1 亿行的事实表加入了一些小的暗表然后分组），它溢出到 tempdb，即使（经过一些调整）CE 非常接近实际的行数，请参阅计划：

寻找解释，我注意到以下内存授予信息：

环境：SQL Server 2012 SP1 Enterprise，服务器 RAM 256 GB，SQL Server 最大内存 200 GB，缓冲池大小 42 GB，工作区最大大小 156 GB（GrantedMemory = 156 * 25% ~= 38 GB）

问题

1. 这是否意味着无论 CE 有多好，查询都没有机会不溢出？因为查询最大 ram 的上限为 38 GB
2. 查询优化器在构建计划时是否不考虑最大查询内存？（强制哈希匹配聚合将消除排序步骤并显着提高查询性能，不幸的是，实际查询来自 Cognos，我们无法控制它）
3. 将 25% 的上限增加到接近 100% 是一个明智的选择吗？（假设可以控制所述服务器访问以限制并发查询请求的数量）

Paste The Plan 上的匿名查询计划

强制哈希匹配聚合（而不是排序 + 流聚合）时，查询始终快 3 - 4 倍。不幸的是，实际查询来自 Cognos，我们无法更改它。

散列聚合计划中没有散列溢出。查询优化器不会选择散列匹配聚合，因为如果我查看散列与流聚合的运算符成本，散列组的 CPU 成本比进行流聚合高 2 - 3 倍。

在流和哈希聚合中，估计的输出行与输入（约 1 亿行）完全相同。

查询使用单个 NC 列存储索引，并且列统计信息都定期更新。

我有一个简单的连接，如下所示：

select * 
from fact_sales f
join dim_company d on f.company_SK = d.company_SK

事实表包含略多于 5 亿条记录（带有 NC 列存储），查询将返回所有记录，但是，联接后的估计行数仅为 3 亿条。直到哈希连接，估计的行数是正确的，只有在连接之后才下降到 3 亿。这是查询的估计计划：

我已经更新了事实表（使用全扫描）和维度表中联接中使用的 SK 列的统计数据，这是每个表的直方图：

这个问题似乎只发生在数据库中的几个维度表上，加入其他维度表不会产生相同类型的基数估计问题 - 关于如何解决这个问题或进一步调查的任何建议？

如果我在查询中添加一个 where 子句，它会正确估计连接之前/之后的行数，例如

select * 
from fact_sales f
join dim_company d on f.company_SK = d.company_SK where company_SK = 1

将估计来自连接的 467,583,000 行，这与直方图中的内容相匹配。

该问题似乎仅在查询中没有任何过滤器时才会发生。它在更大的查询中导致问题（排序溢出）。我已经将范围缩小到这个特定的连接。

我确实有一个 FK 约束，但它们WITH NOCHECK在事实表上已被关闭 ( )（我们被告知关闭它们以便 ETL 可以更快）。不幸的是，重新打开 FK 不是一种选择:(

更新：启用跟踪标志 2301 解决了这个问题：p