从表中读取300％的行，执行计划不正确，并产生内存溢出

Question

整个查询计划和查询：https://www.brentozar.com/pastetheplan/?id=BkgbANxN4

我正在努力处理耗时很多的查询。 明显的原因是错误的行数估计。 我已经尝试过索引和更新统计信息，但是由于查询的执行速度仍然非常慢（我猜错了索引或统计信息），我似乎并没有解决真正的问题。

我需要帮助解释此信息，以便我可以帮助优化查询。我应该在两次执行之间运行哪个索引，哪个DBCC函数或其他内置函数以确保干净的缓存，以及避免使用错误统计信息和全新的统计信息？

例子是

DBCC FREEPROCCACHE
UPDATE STATISTICS *table*

同一查询的另一个瓶颈是这些哈希匹配。最右边的Hash Match会在几秒钟内完成，而左边的Hash Match似乎很难使用最后几分钟的213行。我该怎么做才能找出问题出在这些哈希匹配中？

我还在尝试解决批处理作业中的多个内存溢出问题，在这些工作中，我似乎只能从单个表中优化内存溢出问题。

我有多种排序和散列匹配，其中存在相当长的探测和残差，包括多个表或“表达式”，我认为它们是由SSIS包聚合或设置的。

我应该先解决“第一个”或“最后一个”泄漏吗？第一个是“三个中的第一个”，最后一个最接近叶节点（运算符）。我也想知道下面提到的一些运算符。

您能解释一下这些术语对执行计划说明的含义吗？

1. 建立残差
2. 探针残差
3. 哈希键探针

我相信我理解以下术语：

排序依据：操作员需要数据的顺序

输出列表：操作员正在检索哪些数据以进行输出