WHERE过滤原始行，HAVING过滤分组后结果；WHERE在GROUP BY前执行，不可用聚合函数，只能用原始字段；HAVING在GROUP BY后执行，必须用聚合函数或分组字段，二者执行阶段不同、不可互换。

WHERE 用于过滤原始行，HAVING 用于过滤分组后的结果；有聚合函数的条件必须放 HAVING，没聚合函数但涉及分组字段的条件优先放 WHERE。

WHERE 和 HAVING 的执行阶段不可互换

SQL 查询逻辑顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。这意味着：

• WHERE 在分组前运行，只能访问表中真实存在的字段（如 amount、order_date），不能用 COUNT(*)、AVG(price) 等聚合函数
• HAVING 在分组和聚合计算之后运行，此时原始行已消失，只剩分组键和聚合值，所以它能用 COUNT(*)、SUM(amount)，但不能直接引用未出现在 GROUP BY 或 SELECT 中的原始字段（例如 WHERE 中可用的 customer_name，在 HAVING 中若没出现在 SELECT 或 GROUP BY 就会报 Unknown column）

哪些条件只能写在 WHERE，哪些只能写在 HAVING

错误地把条件放错位置，轻则报错，重则逻辑错误（比如本该筛掉 90% 行却拖到分组后才筛）：

• 只能放 WHERE：单行判断，如 status = 'active'、created_at > '2025-01-01'、product_id IN (1,2,3)
• 只能放 HAVING：依赖聚合结果的判断，如 COUNT(*) > 5、AVG(rating) 、SUM(quantity) > 1000
• 两者都可但效果不同：比如 category_id = 4 —— 放 WHERE 是先剔除其他类目再分组，快；放 HAVING 是全表分组后再筛，慢且多余

HAVING 中能用别名，WHERE 中不能

这是容易踩坑的细节：

• 在 SELECT 中用了别名，如 SELECT dept_id, AVG(salary) AS avg_sal FROM employees GROUP BY dept_id，那么 HAVING avg_sal > 5000 是合法的（MySQL/PostgreSQL 支持）
• 但 WHERE avg_sal > 5000 一定报错，因为 WHERE 执行时 avg_sal 还不存在
• 注意：SQLite 允许 HAVING 引用非分组/非聚合字段（如 HAVING name = 'Alice'），但行为不标准，结果可能不可靠，应避免

组合使用 WHERE + HAVING 是常见且推荐的模式

实际业务中多数高效查询都同时用两者，分工明确：

• WHERE 做「预筛选」：剔除明显无关的数据（如已删除记录、测试数据、时间范围外）
• GROUP BY 做分组
• HAVING 做「后筛选」：基于聚合指标做最终决策（如“平均客单价超 200 的城市”）

示例：SELECT city, COUNT(*) AS user_cnt FROM users WHERE is_verified = 1 GROUP BY city HAVING user_cnt > 1000; —— 先只看认证用户，再按城市分组，最后只保留用户数破千的城市。

最容易被忽略的是：HAVING 的字段来源受限，它不是“另一个 WHERE”，而是分组结果集上的过滤器；一旦混淆执行阶段，就容易写出语义错误或性能极差的语句。