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
4

8 回答 8

81

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

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

于 2008-11-30T08:42:19.407 回答
11

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

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

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

于 2008-11-30T08:46:42.330 回答
7

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

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

于 2008-11-30T10:18:37.170 回答
2

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

于 2008-11-30T08:42:03.930 回答
2

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

于 2013-01-03T19:43:18.813 回答
1

“WHERE”比“HAVING”快！

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

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

Altho 在处理小数据时 - 差异很小，绝对可以忽略

于 2020-04-28T15:46:19.070 回答
1

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

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

于 2020-07-03T03:46:09.573 回答
0

这两个语句将具有相同的性能，因为 SQL Server 足够聪明，可以将两个相同的语句解析为一个相似的计划。

因此，在查询中使用 WHERE 或 HAVING 并不重要。

但是，理想情况下，您应该在语法上使用 WHERE 子句。

于 2015-03-24T07:45:31.197 回答