HAVING用于过滤分组后的聚合结果，而非原始行；其必须使用GROUP BY列或聚合函数，不可用列别名或非聚合字段，适用于数据一致性稽核如金额平衡校验。
HAVING 子句不是用来过滤行，而是过滤分组结果
很多人误把 HAVING 当成 WHERE 的替代品，结果写完发现逻辑不对、性能差、甚至报错。关键区别在于： WHERE 在分组前筛选原始行，HAVING 在 GROUP BY 之后筛选分组聚合结果。做数据一致性稽核时，你真正要检查的是“每个分组是否满足业务规则”，比如“每个部门的员工数不能为 0”“每类订单的总金额必须等于其明细和”，这些都得靠 HAVING。
常见错误现象：SELECT dept, COUNT(*) FROM emp GROUP BY dept HAVING COUNT(*) > 0 看似合理，实则冗余（COUNT(*) 永远 ≥ 1），但换成 HAVING SUM(salary) 就可能暴露异常负值数据——这才是稽核的真实价值点。
用 HAVING 校验主外键引用完整性（无 JOIN 场景）
当无法或不便关联主表与子表（如跨库、权限受限、大表 JOIN 成本高），可改用分组聚合 + HAVING 快速识别孤儿记录。核心思路是：统计子表中每个外键值的出现次数，再筛选出那些在主表中“不该存在”的值。
- 假设
order_items表有order_id，但orders表可能缺失对应记录 - 执行：
SELECT order_id, COUNT(*) AS cnt FROM order_items GROUP BY order_id HAVING COUNT(*) > 0 AND order_id NOT IN (SELECT order_id FROM orders WHERE order_id IS NOT NULL)
- 注意：
NOT IN遇到NULL会整体返回空结果，务必加WHERE order_id IS NOT NULL过滤 - 更安全写法是用
NOT EXISTS，但HAVING本身不支持子查询，所以这个条件必须写在HAVING外层或改用临时表
结合聚合函数做业务逻辑强校验（如金额平衡、数量守恒）
财务、库存等场景常需验证“汇总值 = 明细和”。这类稽核不能只查单条记录，必须分组后比对聚合结果。例如校验每个订单的 total_amount 是否等于其所有 item_amount 之和：
- 先按订单分组，计算明细和：
SUM(item_amount) - 用
HAVING对比：SELECT order_id FROM order_items GROUP BY order_id HAVING ABS(SUM(item_amount) - ( SELECT total_amount FROM orders o WHERE o.order_id = order_items.order_id )) > 0.01 - 这里用
ABS(...)> 0.01是因浮点精度问题，直接!=不可靠 - 若
orders表很大，子查询会拖慢性能；建议提前把orders(order_id, total_amount)建物化视图或临时表，再 JOIN
HAVING 里不能用 SELECT 列别名，也不能用非聚合字段
这是最常踩的坑。比如写成 SELECT dept, AVG(salary) AS avg_sal FROM emp GROUP BY dept HAVING avg_sal > 5000，在 MySQL 8.0+ 或 PostgreSQL 可能通过，但在 SQL Server、Oracle 严格模式下直接报错：Invalid column name 'avg_sal'。标准 SQL 要求 HAVING 中的表达式必须是 GROUP BY 列或聚合函数，不能是列别名。
- 正确写法只能是：
HAVING AVG(salary) > 5000，重复写聚合表达式 - 若表达式复杂（如
ROUND(AVG(salary)*1.1, 2)），建议用 CTE 或子查询封装，避免重复计算和可读性下降 - 另一个典型错误：
HAVING hire_date > '2020-01-01'——hire_date未出现在GROUP BY中，也不是聚合结果，SQL 引擎无法确定该取哪一行的值，必然报错
真正难的不是语法，而是想清楚“你要校验的‘一致性’到底定义在哪个粒度上”——是按主键？按时间分区？还是按业务状态分组？一旦分组维度错了，HAVING 再准也没用。
