HAVING只允许一个子句且必须合并所有聚合条件，因SQL标准限制和解析器语法检查；多条件需用AND/OR连接，字段须为GROUP BY列或聚合函数，别名支持因数据库而异，NULL需显式处理。
HAVING 本身不支持“为不同聚合列分别设置过滤条件”的语法糖，必须把所有条件写在同一 HAVING 子句中，用 AND/OR 组合。 想查“订单数 ≥ 5 且平均金额 > 300 且最近下单时间在 2024 年后”的客户？不能拆成三个 HAVING，只能合并成一个布尔表达式。
为什么不能写多个 HAVING 子句
SQL 标准只允许一个 HAVING 子句，出现在 GROUP BY 之后、SELECT 之前。写两次 HAVING 会直接报语法错误（如 PostgreSQL 报 syntax error at or near "HAVING"，MySQL 报 ERROR 1064）。数据库执行器在解析阶段就拒绝这种结构，不是运行时逻辑问题。
HAVING 中多个聚合条件必须共存于同一布尔表达式
所有过滤目标得塞进一个 HAVING 后面，靠逻辑运算符连接。常见组合方式有：
HAVING COUNT(*) >= 5 AND AVG(amount) > 300 AND MAX(order_date) > '2024-01-01'HAVING SUM(quantity) > 100 OR MIN(price)- 带括号提升可读性：
HAVING (COUNT(*) >= 2) AND (SUM(amount) > 5000 OR AVG(discount) > 0.1)
注意：每个子条件里引用的字段，要么是 GROUP BY 列（如 customer_id），要么是聚合函数（如 AVG(amount)），不能出现裸列（如 status）——除非它也在 GROUP BY 中。
别名在 HAVING 中可用，但跨数据库不一致
MySQL 8.0+ 允许在 HAVING 里直接用 SELECT 中定义的别名，比如：
SELECT customer_id, COUNT(*) AS cnt, AVG(amount) AS avg_amt FROM orders GROUP BY customer_id HAVING cnt >= 5 AND avg_amt > 300;
但 PostgreSQL、SQL Server、SQLite 默认不认这种写法，会报 column "cnt" does not exist。稳妥起见，建议：
- 优先重复写原表达式：
HAVING COUNT(*) >= 5 AND AVG(amount) > 300 - 若表达式复杂（如含
CASE WHEN），用 CTE 提前算好再过滤 - 避免依赖别名，尤其当 SQL 需跨库运行或交给他人维护时
NULL 值会让多条件 HAVING 行为变脆弱
聚合函数对 NULL 的处理差异，可能让某个条件意外失效。例如：
-
COUNT(status)会跳过status为 NULL 的行，而COUNT(*)不会 -
AVG(amount)自动忽略amount IS NULL的记录，但分母变小可能导致结果偏高 - 如果某客户所有
amount都是 NULL，AVG(amount)返回 NULL，整个HAVING条件变成 UNKNOWN，该组被丢弃（三值逻辑）
实际写多条件时，建议显式补 NULL 处理，比如：HAVING COUNT(*) >= 5 AND COALESCE(AVG(amount), 0) > 300，或用 WHERE amount IS NOT NULL 提前清理。
最易被忽略的是执行顺序：所有条件都在内存中逐组判断，没有索引加速。所以 WHERE 能拦住的行（如时间范围、状态码），绝不要拖到 HAVING 里筛——否则分组成本翻倍，还容易因 NULL 或精度问题漏掉本该保留的组。
