WHERE在分组前过滤行，支持索引、不能用聚合函数；HAVING在分组后过滤组，只能用于含GROUP BY的查询，且只能引用分组字段或聚合函数。
WHERE 和 HAVING 都能过滤数据，但执行时机完全不同
WHERE 在分组前筛行，HAVING 在分组后筛组。这不是语义差别，而是 SQL 执行顺序决定的硬约束——HAVING 只能用在含 GROUP BY 的查询里，且只能引用分组字段或聚合函数；WHERE 则不能碰任何聚合结果。
常见错误现象：SELECT user_id, COUNT(*) FROM logs WHERE COUNT(*) > 10 GROUP BY user_id; 直接报错，因为 COUNT(*) 在 WHERE 阶段还没算出来。
-
WHERE过滤的是原始表的每一行，支持索引加速，性能通常更好 -
HAVING过滤的是GROUP BY产出的临时结果集，无法利用原表索引，大数据量时容易变慢 - 如果过滤条件不依赖聚合（比如
status = 'active'），一律放WHERE，别图省事挪到HAVING
什么时候必须用 HAVING 而不是 WHERE
只有当你要按聚合结果做判断时，HAVING 不可替代。比如“找出订单总额超 5000 的客户”，这个“总额”是 SUM(amount)，只能在分组后存在。
使用场景示例：
SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id HAVING SUM(amount) > 5000;
- 错误写法：
HAVING total > 5000—— 别名total在HAVING阶段还不可见，得写SUM(amount)或用子查询 - MySQL 允许
HAVING引用SELECT中的别名，但 PostgreSQL、SQL Server 不支持，跨数据库时慎用 - 如果还要对
HAVING后的结果排序，ORDER BY可以用别名（如ORDER BY total DESC），这和HAVING的限制无关
WHERE + HAVING 混用的典型陷阱
很多人以为先 WHERE 再 HAVING 就是“两层过滤”，但实际逻辑链是：WHERE → GROUP BY → HAVING。中间没有“先缩小数据再分组”的捷径——WHERE 确实能减少分组输入量，但 HAVING 的条件不会反向影响分组行为。
- 错误预期：
WHERE created_at > '2024-01-01' HAVING COUNT(*) > 100并不能保证每个组都有 100 条新数据——它只保证该组在筛选后的数据里总数超 100 - 如果想查“2024 年新增用户中，发帖数超 5 的人”，
WHERE必须先限定时间范围，否则COUNT(*)会包含历史记录 - 聚合函数在
WHERE中非法，在HAVING中合法，但像AVG()、MAX()这类函数本身有 NULL 处理逻辑，HAVING AVG(score) IS NOT NULL和HAVING AVG(score) > 0行为可能不同
没有 GROUP BY 时 HAVING 的行为（MySQL 特例）
标准 SQL 规定：没 GROUP BY 就不能用 HAVING。但 MySQL 5.7+ 默认允许（只要 sql_mode 不含 ONLY_FULL_GROUP_BY），此时整张表被当作一个组处理。
这非常危险：
- 写
SELECT * FROM users HAVING id = 123;看似像WHERE，但它是先全表扫描、再聚合、再过滤，性能极差 - PostgreSQL、SQLite、SQL Server 会直接报错：
ERROR: column "users.id" must appear in the GROUP BY clause - 线上环境若迁移数据库，这类 MySQL “便利”写法会立刻崩，建议主动禁用：
SET sql_mode = 'ONLY_FULL_GROUP_BY';
真正需要单行过滤，就老实用 WHERE；HAVING 的存在意义，始终绑定在分组后的聚合判断上。
