查询优化的“质量”是否因数据库提供者而不同？

Question

我对任何数据库中的查询优化没有一个明确的理解，除了‘它发生’。现在，我刚刚看到了一个“中等”员额，它从优化的角度讨论了使用PostgreSQL CTE的缺陷，因为CTE只进行了一次评估，而且任何可能应用于如何使用CTE的优化，数据库都无法应用。

但是博客文章中的例子似乎很容易优化。

SELECT * FROM foo WHERE id = 500000;

vs

WITH cte AS (
  SELECT * FROM foo
)
SELECT * FROM cte WHERE id = 500000;

如果CTE的计算是在第一个需求上懒洋洋地进行，那么我可以想象这两个查询可以以相同的方式进行优化(至少我认为是这样)。

这让我怀疑..。Server能够比postgres更好地优化这样的查询吗？

数据库在优化查询的范围/能力方面是否存在已知的差异？

Answer 1

问某件事是“更好”还是“更糟”的问题会受到个人意见的影响，所以，你可以轻描淡写。询问查询优化器的行为通常非常广泛，因为在复杂情况下的行为与问题中非常简单的查询不同。

对于Postgres，CTE是所谓的“优化栅栏” (从Postgres 11起)。这意味着Postgres将独立于整个查询优化CTE。在有些情况下，这会导致“更好”(=更快)计划，还有一些情况会导致“糟糕”(=较慢)计划(请注意，最近围绕此设计决定的讨论再次开始，因此在Postgres 11之后的未来版本中可能会发生变化)。

问题中的示例是这样一个例子，在这个例子中，当外部查询的条件没有被推入CTE时，这种方法导致了一个“糟糕”的计划。

Server优化了包括CTE在内的整个查询，因此对于您的示例，Server中的执行计划将被限定为“更好”。

但我在Postgres中也看到了相反的情况:当将(非平凡的)查询的部分移动到CTE中时，结果的计划会更好，因为没有按下的操作会带来更好的估计和更好的(=更快)执行计划。因为我很少使用Server，所以我无法判断是否存在类似的情况。

Answer 2

例如，Server 2017的功能与Server 2016不同。

Answer 3

我可以想象这两个查询可以以相同的方式进行优化。

你为什么要假设这件事？因为主要是：

• 查询优化器很复杂。
• 它们通常不是绿地，它们是随着时间的推移而成长的。

不同的语句可能击中查询优化器的不同区域。它们是一个广泛研究的话题，因此它们在数据库之间也有很大的不同。