在查询周围添加条件会使时间增加 2400% 以上

Question

更新：我会尽快得到查询计划。

我们有一个性能很差的查询，需要 4 分钟才能用于特定组织。在通常的重新编译存储过程和更新统计信息没有帮助之后，我们将 if Exists(...) 重新编写为一个 select count(*)... 以及从 4 分钟到 70 毫秒的存储过程。使 70 毫秒查询需要 4 分钟的条件有什么问题？查看示例

这些都需要 4 分钟以上：

if (
  SELECT COUNT(*)       
    FROM ObservationOrganism  omo
    JOIN Observation          om  ON  om.ObservationID  = omo.ObservationMicID
    JOIN Organism             o   ON  o.OrganismID      = omo.OrganismID
    JOIN ObservationMicDrug   omd ON  omd.ObservationOrganismID = omo.ObservationOrganismID
    JOIN SIRN                 srn ON  srn.SIRNID        = omd.SIRNID
    JOIN OrganismDrug         od  ON  od.OrganismDrugID = omd.OrganismDrugID
  WHERE
    om.StatusCode IN ('F', 'C')
    AND o.OrganismGroupID <> -1
    AND od.OrganismDrugGroupID <> -1
    AND (om.LabType <> 'screen' OR om.LabType IS NULL)) > 0

print 'records';       

-

IF (EXISTS(
  SELECT *       
    FROM ObservationOrganism  omo
    JOIN Observation          om  ON  om.ObservationID  = omo.ObservationMicID
    JOIN Organism             o   ON  o.OrganismID      = omo.OrganismID
    JOIN ObservationMicDrug   omd ON  omd.ObservationOrganismID = omo.ObservationOrganismID
    JOIN SIRN                 srn ON  srn.SIRNID        = omd.SIRNID
    JOIN OrganismDrug         od  ON  od.OrganismDrugID = omd.OrganismDrugID
  WHERE
    om.StatusCode IN ('F', 'C')
    AND o.OrganismGroupID <> -1
    AND od.OrganismDrugGroupID <> -1
    AND (om.LabType <> 'screen' OR om.LabType IS NULL))

print 'records'

这一切都需要 70 毫秒：

Declare @recordCount INT;
SELECT @recordCount = COUNT(*)       
    FROM ObservationOrganism  omo
    JOIN Observation          om  ON  om.ObservationID  = omo.ObservationMicID
    JOIN Organism             o   ON  o.OrganismID      = omo.OrganismID
    JOIN ObservationMicDrug   omd ON  omd.ObservationOrganismID = omo.ObservationOrganismID
    JOIN SIRN                 srn ON  srn.SIRNID        = omd.SIRNID
    JOIN OrganismDrug         od  ON  od.OrganismDrugID = omd.OrganismDrugID
  WHERE
    om.StatusCode IN ('F', 'C')
    AND o.OrganismGroupID <> -1
    AND od.OrganismDrugGroupID <> -1
    AND (om.LabType <> 'screen' OR om.LabType IS NULL);

IF(@recordCount > 0)
  print 'records';

为什么将完全相同的 Count(*) 查询移动到 if 语句中会导致这种退化，或者为什么“存在”比 Count 慢，这对我来说没有意义。我什至在select CASE WHEN Exists() 中尝试了exists()，它仍然是4 多分钟。

Answer 1

鉴于提到了我之前的答案，我将尝试再次解释，因为这些事情非常棘手。所以是的，我认为您遇到了与the other question 相同的问题。即row goal 问题。

因此，为了尝试解释造成这种情况的原因，我将从引擎可以使用的三种连接类型开始（并且非常明确地）：循环连接、合并连接、哈希连接。循环连接就像它们听起来的那样，是一组数据的嵌套循环。 Merge Joins 采用两个排序的列表，并在它们之间同步移动。哈希连接将较小集合中的所有内容放入文件柜，然后在文件柜装满后查找较大集合中的项目。

所以性能方面，循环连接几乎不需要设置，如果您只是在寻找少量数据，它们确实是最佳选择。就任何数据大小的连接性能而言，合并是最好的，但要求数据已经排序（这种情况很少见）。哈希联接需要大量设置，但允许快速联接大型数据集。

现在我们来了解您的查询以及COUNT(*) 和EXISTS/TOP 1 之间的区别。因此，您看到的行为是优化器认为该查询的行确实很可能（您可以通过在不分组的情况下规划查询并查看它认为在最后一步将获得多少记录来确认这一点）。特别是它可能认为对于该查询中的某个表，该表中的每条记录都将出现在输出中。

“尤里卡！”它说，“如果此表中的每一行都在输出中结束，要查找是否存在，我可以在整个过程中进行非常便宜的启动循环连接，因为即使它对于大型数据集来说很慢，但我只需要一行。”但随后它没有找到该行。而且再也找不到了。而现在，它正在使用其可支配的最不有效的方法对大量数据进行迭代，以清除大量数据。

相比之下，如果您要求数据的完整计数，它必须根据定义找到每条记录。它会查看大量数据并选择最适合迭代整个数据集的选项，而不仅仅是一小部分数据。

另一方面，如果它确实是正确的并且记录之间的相关性非常好，那么它会以尽可能少的服务器资源找到您的记录，并最大限度地提高其整体吞吐量。