having子句中禁止直接嵌套任何子查询（含关联子查询），因sql执行顺序为group by→聚合计算→having，子查询缺乏分组上下文，主流数据库均报语法错误；正确方案是用窗口函数（如avg(count(*)) over()）或cte/派生表提前物化基准值。
HAVING里不能直接写关联子查询，写了就报错，根本跑不起来
标准 SQL（包括 MySQL 8.0+、PostgreSQL、SQL Server）明确禁止在 HAVING 子句中嵌套未关联的子查询，更别说关联子查询了。你如果真写了类似 HAVING COUNT(*) > (SELECT AVG(cnt) FROM (...)) 或 HAVING SUM(price) > (SELECT budget FROM dept WHERE dept.id = orders.dept_id) 这种结构，数据库会直接拒绝执行，报错如：
-
ERROR: subquery in HAVING clause not allowed（PostgreSQL） -
Invalid use of group function（MySQL，当子查询含聚合时） -
Incorrect syntax near 'SELECT'（SQL Server）
这不是性能差，是语法非法——连执行阶段都进不去。
为什么有人觉得“HAVING + 子查询”慢？其实是误把子查询塞进了错误层级
真实场景中，所谓“慢”，往往来自两种典型误用：
- 把本该在
WHERE阶段过滤的条件硬塞进HAVING，比如HAVING created_at > '2024-01-01'（created_at是单行字段，不是聚合结果），导致分组前没筛数据，GROUP BY 处理了全部百万行，再逐组判断——这锅不是子查询的，是逻辑放错位置 - 在外部查询的
SELECT或WHERE中用了关联子查询，然后又在HAVING里重复引用同一逻辑（比如先SELECT (SELECT ...)再HAVING (SELECT ...) > 10），结果子查询被调用两次，且第二次无法复用缓存或计划
真正执行关联子查询的环节，永远在 WHERE、SELECT 或 ON 条件里，而不是 HAVING。
想实现“按动态聚合基准过滤分组”，正确路径只有两条
如果你的真实需求是：「查订单数超过全站客户平均订单数的客户」或「每个部门中项目金额 > 该部门人均薪资×3 的项目」，必须绕开 HAVING 写子查询这条路：
-
首选窗口函数：在
GROUP BY后立刻用OVER()算出全局/分区基准，再用WHERE过滤。例如：AVG(COUNT(*)) OVER()必须嵌套在窗口内，不能写成AVG(order_cnt) OVER()（order_cnt此时尚未生成） -
次选 CTE 或派生表：把聚合 + 子查询逻辑封装成独立查询，再和主表
JOIN或用于IN。CTE 在 PostgreSQL/SQL Server 中更易物化；MySQL 5.7 只能靠FROM (SELECT ... GROUP BY ... HAVING ...) AS t
注意：CTE 或子查询里的 HAVING 是合法的，因为它处于独立查询层级，但外层不能再对它“再套一层 HAVING + 子查询”。
最容易被忽略的性能断点：GROUP BY 字段没索引，HAVING 再怎么改都白搭
就算你把所有逻辑都挪到 WHERE 和 CTE 里，只要 GROUP BY 的字段（如 customer_id、dept_id）没有索引，数据库仍要全表扫描 + 文件排序（Using filesort / Using temporary）。这时：
-
EXPLAIN里看到type: ALL或Extra含Using filesort，说明分组本身已成瓶颈 - 复合索引顺序必须匹配
GROUP BY字段顺序，例如GROUP BY user_id, status要建INDEX (user_id, status)，反过来效果极差 - MySQL 8.0+ 支持函数索引，对
GROUP BY DATE(created_at)可建INDEX (DATE(created_at))
别在 HAVING 上死磕优化——它只是个分组后门卫，真正的吞吐量取决于前面那道大门（WHERE）和地基（索引）是否牢固。
