核心思路是用子查询预先计算全表平均值作为标量常量，再在having中与各分组聚合结果比较；因sql不允许在having中直接引用跨层级聚合，故必须分离计算。
用子查询先算出整体平均值
核心思路是：先单独算出全表的平均值，再拿这个值去和每个分组的聚合结果比较。不能在同一个 GROUP BY 查询里直接用 AVG() 去和分组结果比——SQL 不允许在 HAVING 里引用未聚合的列或跨层级的聚合结果。
常见错误写法：HAVING AVG(sales) > AVG(sales)，这会报错或返回意外结果，因为右边的 AVG(sales) 是按分组计算的，不是全表平均。
- 必须把全表平均值作为标量值提前算好，最稳妥方式是用子查询
- 子查询要加括号，且只能返回单个值（否则报错
Subquery returns more than 1 row） - 如果表为空，子查询返回
NULL，会导致整个HAVING判断为UNKNOWN，该分组被过滤掉——这是符合三值逻辑的正常行为
在 HAVING 中与子查询结果比较
HAVING 是唯一能对分组后聚合值做条件筛选的地方，它作用于 GROUP BY 之后的结果集。这里的关键是把子查询当做一个“常量”来用。
示例（查各地区平均销售额高于全表平均的地区）：
SELECT region, AVG(sales) AS avg_region_sales FROM orders GROUP BY region HAVING AVG(sales) > (SELECT AVG(sales) FROM orders);
- 子查询
(SELECT AVG(sales) FROM orders)在外部查询执行前只运行一次，性能可接受 - 若字段可能为
NULL，AVG()会自动忽略，无需额外处理；但若想包含NULL为 0，得先用COALESCE(sales, 0) - 注意数据类型：如果
sales是整型，子查询返回DECIMAL，比较时隐式转换通常没问题，但显式转成CAST(... AS DECIMAL)更安全
窗口函数方案（MySQL 8.0+/PostgreSQL/SQL Server）
如果数据库支持窗口函数，可以用 AVG() OVER() 避免子查询，逻辑更直观，且便于扩展（比如同时显示全表均值和分组均值）。
示例：
SELECT region, avg_region_sales
FROM (
SELECT region, AVG(sales) AS avg_region_sales,
AVG(AVG(sales)) OVER() AS overall_avg
FROM orders
GROUP BY region
) t
WHERE avg_region_sales > overall_avg;
- 内层
GROUP BY先算各分组均值，外层用窗口函数对这些均值再求平均——等价于全表平均 - 不能写成
AVG(sales) OVER()直接套在原表上，那算的是原始行粒度的均值，和分组后均值的比较逻辑不一致 - 窗口函数方案在大数据量下不一定更快，因为仍需两次扫描（一次分组、一次窗口），但可读性更好，也方便加排序或分页
WHERE 和 HAVING 混用时的陷阱
如果查询中已有 WHERE 条件（比如只看 2023 年订单），全表平均值必须和分组基于同一数据子集——否则比较失去意义。
- 错误做法：子查询没加
WHERE year = 2023，而主查询加了，导致拿「全历史平均」和「2023 各地区平均」比较 - 正确做法：子查询必须复刻主查询的过滤条件，保持数据口径一致
- 推荐把公共过滤条件提取为 CTE，避免重复写，也降低出错概率
CTE 示例：
WITH filtered AS ( SELECT * FROM orders WHERE order_date >= '2023-01-01' ) SELECT region, AVG(sales) FROM filtered GROUP BY region HAVING AVG(sales) > (SELECT AVG(sales) FROM filtered);
实际写的时候最容易漏掉子查询里的过滤条件，尤其是多层嵌套或动态 SQL 场景下——这里没有银弹，只能靠人工核对或测试用例覆盖。
