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
【问题讨论】：
标签： sql performance grouping if-statement
理论（理论我的意思是SQL Standard）说 WHERE 在返回行之前限制结果集，而 HAVING 在带来所有行之后限制结果集。所以 WHERE 更快。在这方面，在符合 SQL 标准的 DBMS 上，仅在不能将条件放在 WHERE 上的情况下使用 HAVING（如某些 RDBMS 中的计算列）。
您可以查看两者的执行计划并自行检查，没有什么比这更好的了（在您的特定环境中使用您的数据测量您的特定查询。）
【讨论】：
这可能取决于引擎。例如，MySQL 几乎在链中最后应用 HAVING，这意味着几乎没有优化空间。来自manual：
HAVING 子句几乎在最后应用，就在项目发送到客户端之前，没有优化。 （LIMIT 在 HAVING 之后应用。）
我相信这种行为在大多数 SQL 数据库引擎中都是相同的，但我不能保证。
【讨论】：
这两个查询是等效的，您的 DBMS 查询优化器应该识别这一点并生成相同的查询计划。可能不是，但这种情况很容易识别，所以我希望任何现代系统 - 甚至 Sybase - 都能处理它。
HAVING 子句应该用于在组函数上应用条件，否则它们可以移动到 WHERE 条件中。例如。例如，如果您想将查询限制为 COUNT(DZIALU) > 10 的组，则需要将条件放入 HAVING 中，因为它作用于组，而不是单个行。
【讨论】：
我希望 WHERE 子句会更快，但它们可能会优化到完全相同。
【讨论】：
说他们会优化并不是真正控制并告诉计算机该做什么。我同意使用 have 不能替代 where 子句。有一种特殊的用法，即通过使用 sum() 之类的东西应用于组，并且您希望将结果集限制为仅显示 sum() > 本身大于 100 的组。在组上工作，在行上工作。它们是苹果和橙子。所以说真的，它们不应该被比较，因为它们是两种截然不同的动物。
【讨论】：
“WHERE”比“HAVING”快！
查询的更复杂的分组是 - 比较慢的“HAVING”将执行比较，因为：“HAVING”“过滤器”将处理更大量的结果，它也是额外的“过滤器”循环
“HAVING”也会使用更多内存（RAM）
尽管处理小数据时 - 差异很小，完全可以忽略
【讨论】：
如果我们与大量数据相比，“Having”会更慢，因为它适用于记录组，而“WHERE”适用于行数..
“Where”在引入所有行之前限制结果，而“Having”在引入所有行之后限制结果
【讨论】：
这两个语句将具有相同的性能，因为 SQL Server 足够聪明，可以将两个相同的语句解析为一个相似的计划。
因此，在查询中使用 WHERE 还是 HAVING 并不重要。
但是，理想情况下，您应该在语法上使用 WHERE 子句。
【讨论】：