WHERE 筛行、HAVING 筛组是本质区别；WHERE 不能用聚合函数因执行早于分组，HAVING 必须配合 GROUP BY 才符合语义；WHERE 提前过滤大幅提升性能，错用 HAVING 会导致全量聚合，性能骤降。
WHERE 筛的是行，HAVING 筛的是组——这是唯一需要记住的本质。 其他所有差异（能不能用 COUNT()、执行快慢、报不报错）都从这个事实自然推导出来。
WHERE 为什么不能用聚合函数？
因为数据库根本还没算出聚合值。在执行 WHERE 阶段，数据还是一条一条的原始记录，SUM(price) 或 AVG(salary) 还不存在。
- ✅ 合法：
WHERE order_date > '2025-01-01'（单行字段可直接判断） - ❌ 报错：
WHERE SUM(amount) > 1000（此时SUM尚未生成，语法直接拒绝） - ⚠️ 常见错觉：有人以为加了
GROUP BY就能让WHERE用聚合函数——不行，执行顺序固定，WHERE永远早于GROUP BY。
HAVING 必须配合 GROUP BY 吗？
逻辑上是的，语义上也应如此。虽然某些数据库（如 MySQL）允许没有 GROUP BY 的 HAVING（把整张表当一个组），但这种写法模糊、不可移植、易引发误解。
- ✅ 推荐写法：
SELECT COUNT(*) FROM users GROUP BY 1 HAVING COUNT(*) > 100（显式分组，意图清晰） - ❌ 避免写法：
SELECT COUNT(*) FROM users HAVING COUNT(*) > 100（无GROUP BY，依赖方言，SQL 标准不鼓励） - ? 注意：
HAVING可引用SELECT中定义的聚合别名，比如SELECT dept, COUNT(*) AS cnt FROM emp GROUP BY dept HAVING cnt > 3—— 这是合法且常见的。
WHERE 和 HAVING 混用时，性能怎么差出一个数量级？
关键在于数据量缩减时机。WHERE 能让数据库跳过大量原始行；HAVING 则必须先把所有分组和聚合全算完，再扔掉不满足条件的组。
- ? 场景：查“2025 年销售额超 5 万元的客户”。
- ✅ 高效：
WHERE order_year = 2025先筛掉 90% 历史订单，再GROUP BY customer_id聚合，最后HAVING SUM(amount) > 50000 - ❌ 低效：把
order_year = 2025放进HAVING，数据库得先对全部年份做分组求和，内存爆、IO 多、耗时长。 - ? 查看执行计划时，注意
rows_examined：WHERE 优化后该值应显著下降；HAVING 前置则毫无改善。
最容易被忽略的点是：WHERE 和 HAVING 不是“选哪个更顺手”的问题，而是“数据库根本不允许你乱换位置”的硬性流程约束。写错不是结果不准，是直接报错或隐式降级——比如把本该 WHERE 的条件塞进 HAVING，查询可能跑通，但性能已悄然崩坏，而你毫无察觉。
