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 或精度问题漏掉本该保留的组。