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) 、<code>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”，而是分组结果集上的过滤器；一旦混淆执行阶段，就容易写出语义错误或性能极差的语句。
