哪个 SQL 语句更快？（拥有与在哪里......）

Posted 2023-02-16

技术标签:

【中文标题】哪个 SQL 语句更快？（拥有与在哪里......）【英文标题】：Which SQL statement is faster? (HAVING vs. WHERE...) 【发布时间】：2010-09-24 15:00:51 【问题描述】：

SELECT NR_DZIALU, COUNT (NR_DZIALU) AS LICZ_PRAC_DZIALU
    FROM  PRACOWNICY
    GROUP BY NR_DZIALU
    HAVING NR_DZIALU = 30

或

SELECT NR_DZIALU, COUNT (NR_DZIALU) AS LICZ_PRAC_DZIALU
    FROM PRACOWNICY
    WHERE NR_DZIALU = 30
    GROUP BY NR_DZIALU

【问题讨论】：

仅供参考，我已经编译了有关有子句的优化技术，以防有人希望优化查询。 junaidtechblog.wordpress.com/2019/09/04/… 【参考方案1】：

理论（理论我的意思是SQL Standard）说 WHERE 在返回行之前限制结果集，而 HAVING 在带来所有行之后限制结果集。所以 WHERE 更快。在这方面，在符合 SQL 标准的 DBMS 上，仅在不能将条件放在 WHERE 上的情况下使用 HAVING（如某些 RDBMS 中的计算列）。

您可以查看两者的执行计划并自行检查，没有什么比这更好的了（在您的特定环境中使用您的数据测量您的特定查询。）

【讨论】：

在 Sybase DB 下它对于 150 行具有相同的执行时间:) 我说的是执行计划，在这里你可以看到数据库将执行哪些步骤来获取你的数据。 150 行太少，无法注意到执行时间的任何差异，但如果计划不同，那么这对具有更多行的表很重要。在运行查询之前“设置显示计划”... ... 应该为您提供 Sybase 上的数据。查看此链接了解更多信息：groups.google.com/group/comp.databases.sybase/browse_thread/… FWIW，在 MS SQL Server 2005 中，执行计划是相同的。这不取决于表和子集的大小以及整个表中 where 子句的成本与子集的 where 子句的成本吗？【参考方案2】：

这可能取决于引擎。例如，mysql 几乎在链中最后应用 HAVING，这意味着几乎没有优化空间。来自manual：

HAVING 子句几乎在最后应用，就在项目发送到客户端之前，没有优化。（LIMIT 在 HAVING 之后应用。）

我相信这种行为在大多数 SQL 数据库引擎中都是相同的，但我不能保证。

【讨论】：

嘿，“这取决于引擎，但我相信它们的行为都是这样的”:-) 好吧，我只能说我知道的，其余的推测一下:)【参考方案3】：

这两个查询是等效的，您的 DBMS 查询优化器应该识别这一点并生成相同的查询计划。可能不是，但这种情况很容易识别，所以我希望任何现代系统 - 甚至 Sybase - 都能处理它。

HAVING 子句应该用于在组函数上应用条件，否则它们可以移动到 WHERE 条件中。例如。例如，如果您想将查询限制为 COUNT(DZIALU) > 10 的组，则需要将条件放入 HAVING 中，因为它作用于组，而不是单个行。

【讨论】：

【参考方案4】：

我希望 WHERE 子句会更快，但它们可能会优化到完全相同。

【讨论】：

【参考方案5】：

说他们会优化并不是真正控制并告诉计算机该做什么。我同意使用 have 不能替代 where 子句。有一种特殊的用法，即通过使用 sum() 之类的东西应用于组，并且您希望将结果集限制为仅显示 sum() > 本身大于 100 的组。在组上工作，在行上工作。它们是苹果和橙子。所以说真的，它们不应该被比较，因为它们是两种截然不同的动物。

【讨论】：

【参考方案6】：

“WHERE”比“HAVING”快！

查询的更复杂的分组是 - 比较慢的“HAVING”将执行比较，因为：“HAVING”“过滤器”将处理更大量的结果，它也是额外的“过滤器”循环

“HAVING”也会使用更多内存（RAM）

尽管处理小数据时 - 差异很小，完全可以忽略

【讨论】：

【参考方案7】：

如果我们与大量数据相比，“Having”会更慢，因为它适用于记录组，而“WHERE”适用于行数..

“Where”在引入所有行之前限制结果，而“Having”在引入所有行之后限制结果

【讨论】：

【参考方案8】：