HAVING只能用于过滤聚合结果或GROUP BY字段，所有非聚合、非分组字段的过滤必须放在WHERE中；WHERE可走索引加速，HAVING则全表扫描且不走索引。
WHERE 能过滤的，别塞进 HAVING
HAVING 本质是分组后对结果集做内存遍历，不走索引、不减少扫描行数。只要条件能写在 WHERE 里，就绝不要挪到 HAVING——这不是风格问题，是执行计划层面的硬伤。
常见错误现象：HAVING created_at > '2024-01-01'（created_at 是单行字段），PostgreSQL 报错 column "created_at" must appear in the GROUP BY clause，MySQL 严格模式下同样失败。
- 所有非聚合、非
GROUP BY字段的过滤，必须放在WHERE -
WHERE可用索引加速扫描；HAVING完全跳过索引，纯 CPU 计算 - 数据量越大，性能差距越明显：10 万行表中，
WHERE版本可能只扫 2 万行，HAVING版本必扫全表
HAVING 只能用聚合结果或 GROUP BY 字段
你不能在 HAVING 里直接引用原始列，比如 status 或 user_id，除非它已出现在 GROUP BY 子句中。这不是 MySQL 的宽容特性，而是 SQL 标准的逻辑约束。
错误写法：SELECT user_id, COUNT(*) FROM logs GROUP BY user_id HAVING status = 'active' —— status 既没聚合也没分组，语义上无法确定“这个组的 status 是什么”。
- 正确解法一：把字段加进
GROUP BY，如GROUP BY user_id, status，再写HAVING status = 'active' - 更合理解法二：提前用
WHERE status = 'active'过滤，再GROUP BY user_id - MySQL 旧版本允许“隐式分组”，但一旦迁移到 PostgreSQL 或开启
ONLY_FULL_GROUP_BY，立刻报错
别名在 HAVING 中不可用，重复写聚合表达式
HAVING 解析发生在 SELECT 列别名生成之前，所以 HAVING cnt > 10 这种写法在绝大多数数据库里都会失败，不是语法糖，是解析阶段的硬限制。
错误示例：SELECT user_id AS uid, COUNT(*) AS cnt FROM t GROUP BY user_id HAVING cnt > 10
- 必须写成
HAVING COUNT(*) > 10或HAVING COUNT(1) > 10 - 如果
SELECT用了复杂表达式，如ROUND(AVG(score), 2)，HAVING也得完全一致：HAVING ROUND(AVG(score), 2) > 85 - 别为了省几个字符牺牲可移植性——不同数据库对别名的支持差异极大，PostgreSQL 直接拒，SQL Server 表面允许但行为不一致
聚合函数精度和 NULL 处理会影响 HAVING 结果
HAVING AVG(score) > 80 看似简单，但实际执行时受 NULL 和浮点精度双重影响。AVG() 自动忽略 NULL，但如果某组全是 NULL，结果为 NULL，NULL > 80 返回 unknown，该组被过滤掉——这未必是你想要的逻辑。
- 显式处理 NULL：
HAVING AVG(COALESCE(score, 0)) > 80或加WHERE score IS NOT NULL前置过滤 - 精度偏差风险：若
SELECT用ROUND(AVG(score), 1)，而HAVING写AVG(score) > 80，可能因舍入导致同一组在 SELECT 和 HAVING 中被判定不一致 - 建议统一使用原始聚合表达式，避免中间 ROUND/CAST 干扰判断逻辑
最常被忽略的一点：HAVING 优化不是“怎么写 HAVING”，而是“怎么不让 HAVING 承担不该干的活”。它的唯一合法职责，就是基于聚合结果做最终筛选。其余所有过滤动作，都应该在它之前完成——哪怕多写一行 WHERE，也比在 HAVING 里硬扛性能雪崩强。
