流聚合排序？

回答你的第一个问题：

当我没有分组依据时，为什么查询中会有一个流聚合。我猜这与正在合并的连接及其进行某种排序有关吗？

SQL Server 正在有效地重写您的查询。这个查询：

select Object1.Column1
FROM Object2 Object3 WITH (ROWLOCK)
INNER JOIN Object4 Object1 WITH (ROWLOCK) ON Object3.Column2 = Object1.Column1
WHERE Object3.Column2 in (SELECT Column2 FROM Object5)
or Object3.Column3 in (SELECT Column2 FROM Object5);

也可以这样写：

select Object1.Column1
FROM
(
select Object3.Column2
FROM Object2 Object3 WITH (ROWLOCK)
WHERE Object3.Column2 in (SELECT Column2 FROM Object5)

UNION

select Object3.Column2
FROM Object2 Object3 WITH (ROWLOCK)
WHERE Object3.Column3 in (SELECT Column2 FROM Object5)
) Object3 
INNER JOIN Object4 Object1 WITH (ROWLOCK) ON Object3.Column2 = Object1.Column1;

这就是为什么您Object2在查询计划中有两种不同的访问方法。该Merge Join (Concatenation)操作实际上不是合并连接。它只是实施UNION ALL并组合结果。您提到的流聚合按Object3.Column2. 这既可以从中删除重复项Merge Join (Concatenation)，也可以对数据进行排序，以便它可以在以下MERGE JOIN对象 4 中使用。

回答你的第二个问题：

其次，更重要的是，为什么 13 进入流的估计总计结果为 24,595,900？这导致了 Object4 扫描聚集索引而不是嵌套循环的第二个问题。我不得不将查询拆分为两个查询而不是使用 OR，并且连接变成嵌套循环并查找 Object4。

它看起来像一个错误。经过一番搜索，我找到了 Paul White 的一篇文章来解释这个问题。如果您想投票或将自己添加为受影响，该错误将报告给Connect 。

简而言之，基数估计为 24595900，因为四舍五入Object2后 27328800（表基数 ）* 0.9 = 24595900。您使用的是 SQL Server 2008，因此使用旧版 CE 计算：

2014 年之前的基数估计器也出现了类似的问题，但最终估计固定在估计的半连接输入的 90%（出于与反向固定 10% 谓词估计相关的娱乐原因，这太分散了进入）。

我建议通读整篇文章。这个问题有点难以总结，但我会尝试通过在接近尾声的地方引用部分文本来做到这一点：

基数估计器使用具有 100% 选择性的 Fixed Join 计算器。因此，半连接的估计输出基数与其输入相同，这意味着历史表中的所有 113443 行都应符合条件。

该错误的确切性质是半连接选择性计算遗漏了输入树中位于联合之外的任何谓词。在下图中，半连接本身缺少谓词意味着每一行都符合条件；它忽略了连接下方谓词的影响（union all）。

2014 年之前的基数估计器也出现了类似的问题，但最终估计固定在估计的半连接输入的 90%（出于与反向固定 10% 谓词估计相关的娱乐原因，这太分散了进入）。

像您一样拆分查询应该可以防止出现此问题。您还可以通过使用重写查询来获得一些运气UNION（请参阅本文中的示例 4）。