sql查询的成本评估

Question

我最近在一次采访中被问到这个问题：

假设我有一个sql查询，如

select A.a
from A JOIN B on A.b=B.c

现在，通常和的有效方法是，在这种情况下，首先根据连接条件过滤来自A和B的记录，然后执行连接。

面试官让我给出一个场景，，(不仅仅是上面给出的选择，还有其他的选择)，在中，最有效的方法是先进行连接，然后选择。

当时我想不出任何这样的操作人员或场景，也无法回答，即使现在我也无法想到it.Can，有人告诉我有这样的场景吗？

更新：上面的查询只是解释正常执行过程的一个例子。答案并不是，也肯定不会仅仅是一个经过挑选的操作，而是包括一些其他操作，如联合、交叉等。面试官想知道其他情况。

Answer 1

当筛选的成本高于连接谓词的成本时，在join之前计算where标准可能会更有效。

create table Users (id int, name nvarchar(255));
create table Comments (userid int, commentText nvarchar(max));

create index IX_Comments_Users on Comments (userid);

select c.*
from Comments c
inner join Users u on c.userid = u.id
where u.name = 'foobar' and c.commentText like '%f%'

虽然我只是猜测(而且非常糟糕)，但查询计划希望从Users获得结果，并在Comments上执行索引查找( rid查找)，然后在最后执行like。

但是，在现代数据库平台上，您不必考虑这个问题:优化器将使用统计信息来估计行数，并且通常选择最有效的查询计划。我必须首先显式调优查询以计算where子句的唯一一次是在处理优化器没有模式信息的链接服务器时。

exec sp_addlinkedserver 'linkedServer','SQL Server';

create table big_table (id int, userid int, ... wide table too ...);

-- this produced a query plan on SQL Server 2008 which did the join, then a filter
-- I think I solved it by doing a TOP(int.max) hack or a remote join... don't remember
select *
from big_table b
inner join [linkedServer].someDb.dbo.small_table s on b.id = s.id
where s.someOtherColumn = 'a'

但是，我强调oncemore，您在查询中所写的内容与查询的执行方式无关。Server和朋友在他们所能做的优化方面可能是非常出色的。例如，如果存在具有相同条件的索引视图，则在执行时甚至可能不会对您的条件进行评估--对于筛选的索引也可以这样说。

学习阅读查询计划，热爱查询计划，并回答这些问题：“当生成的查询计划不太理想时，性能会导致问题”。使用SQL的任何其他方法都是神秘的想法。

Answer 2

这些注释基于Oracle和Server。这将有助于将特定的数据库作为标记，因为这类问题的答案可能是特定于数据库的。

查询计划器决定在连接之前还是之后过滤记录，除非您使用子表之类的东西来混淆它。

我认为基于成本的优化器希望在联接之后进行筛选的唯一原因是，如果它需要外部连接的输出来计算某项，或者谓词需要跨两个表的calc。

在示例查询中，它将对两个表进行某种扫描，然后进行某种联接。

它不能/不会在连接之前‘预筛选’记录，基于连接谓词，因为它必须事先做一些散列/连接来识别记录，这是工作的两倍，而基于成本的优化器不会选择两次工作。

如果你看一个查询计划..。它总是在SELECT是计划中的最后一个之前进行连接。因此，你不妨澄清你的第二项声明。

我想你的面试官一定是在暗示别的什么，但我不确定是什么。

事实上，优化器总是试图减少进入join运算符的记录(通过过滤)，因此join运算符所做的工作较少。