聚合函数不能在WHERE中使用，是因为SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，WHERE在分组前执行，此时聚合值尚未计算；而HAVING在GROUP BY之后运行，可对已分组结果使用COUNT、SUM等聚合函数进行过滤。
聚合函数不能直接在 WHERE 中使用，是因为 SQL 执行顺序决定了 WHERE 阶段根本还没算出聚合值——它只看到原始行，看不到“每组有多少条”或“某列总和是多少”。
WHERE 和 HAVING 的执行时机差异
WHERE 在分组前运行，过滤的是单行数据；HAVING 在 GROUP BY 之后运行，过滤的是已计算好的分组结果。这是硬性顺序：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。
- 你在
WHERE里写COUNT(*) > 5，数据库会直接报错，比如 PostgreSQL 的ERROR: aggregate functions are not allowed in WHERE，MySQL 的Invalid use of group function -
HAVING是唯一允许放COUNT()、SUM()、AVG()等的地方，且必须跟在GROUP BY后面 - 注意：
HAVING里引用别名（如HAVING total_cnt > 10）在 MySQL/PostgreSQL 中可行，但为兼容旧版本或 SQLite，建议复写表达式：HAVING COUNT(*) > 10
用子查询绕过 WHERE 限制的实操要点
当需要把聚合结果和其他表关联，或做多层逻辑判断时，HAVING 不够用，得靠子查询把聚合结果当“临时表”来用。
- 子查询必须带别名，否则 PostgreSQL/MySQL 8.0+ 会报
ERROR: subquery in FROM must have an alias - JOIN 时注意空值陷阱：如果分组字段（如
region）含NULL，直接ON s.region = t.region会丢掉所有NULL行；稳妥做法是先在子查询里过滤或用WHERE region IS NOT NULL - 示例：查每个区域订单数超 100 的用户明细
SELECT s.* FROM sales s JOIN (SELECT region, COUNT(*) c FROM sales GROUP BY region HAVING COUNT(*) > 100) t ON s.region = t.region
窗口函数比嵌套查询更稳的场景
当你既要聚合计算（如区域总销售额），又不想丢失原始行（比如保留每笔订单的明细），硬套 GROUP BY + JOIN 容易漏条件、重复聚合、空值出错——这时候窗口函数是更干净的选择。
-
SUM(amount) OVER (PARTITION BY region)会在每行上补上该区域总额，不改变行数 -
PARTITION BY语义等价于GROUP BY的分组逻辑，但不折叠；空值默认被归为同一组，如需排除，加WHERE region IS NOT NULL - 对比错误写法：
SELECT s.*, t.region_total FROM sales s JOIN (SELECT region, SUM(amount) region_total FROM sales GROUP BY region) t ON s.region = t.region—— 若s.region有NULL，这部分记录就没了
真正容易被忽略的不是语法对错，而是执行代价：把本该下推到 WHERE 的条件（比如时间范围、状态码）错塞进 HAVING，会让数据库白算几百万组，最后全扔掉——尤其在高基数分组列上，可能直接 OOM。
