HAVING子句强制数据库物化全量分组结果，无法下推过滤，导致内存溢出风险；MySQL视图含HAVING即禁用MERGE改走DERIVED路径，PG/SQL Server亦因HAVING阻碍优化而加剧资源消耗。
HAVING 子句本身不直接导致内存溢出，但它几乎必然触发全量分组 + 全量排序路径，而数据库无法对视图内的 HAVING 下推过滤，结果就是中间结果集被迫物化进内存。
MySQL 视图里写 HAVING 就等于强制物化
只要视图定义中出现 HAVING，MySQL 就放弃 MERGE 优化策略，改走 DERIVED 物化路径——整个 GROUP BY 结果必须先算完、存成临时表，再应用 HAVING 过滤。哪怕你只查 SELECT * FROM my_view LIMIT 10，EXPLAIN 也会显示 select_type = DERIVED，且 rows 接近底层表总行数。
- 视图定义含
HAVING SUM(amount) > 10000→ 触发物化，Created_tmp_disk_tables持续上涨 -
SHOW STATUS LIKE 'Sort_scan'值飙升，说明大量分组后排序在内存中反复发生 - 别指望外层加
WHERE id IN (1,2,3)能提前过滤：HAVING 在 GROUP BY 之后，WHERE 在之前，两者作用阶段完全不同
PostgreSQL / SQL Server 对 HAVING 的处理更隐蔽但更危险
PostgreSQL 不允许视图定义里直接写 HAVING（语法报错），但若视图内嵌了带 HAVING 的 CTE 或子查询，执行时仍会生成 Materialize 节点；SQL Server 则允许，但 HAVING 会阻止谓词下推，导致 sys.dm_exec_query_stats 中 max_used_grant_kb 异常高。
- EXPLAIN (ANALYZE, BUFFERS) 显示
Materialize节点下Actual Total Workers> 1 且Temp Blocks Written> 0 → 已落盘 - SQL Server 执行计划里出现
Hash Match (Aggregate)后紧接Filter（对应 HAVING）→ 分组已全量完成，过滤只是最后一步 - CTE 内用
HAVING，外层再LIMIT？基本没下推可能，Plan Rows 仍是百万级
HAVING 和索引根本是两套体系，别幻想靠调 sort_buffer_size 救命
HAVING 过滤的是分组后的聚合值（如 COUNT(*), SUM()），而索引只能加速原始字段的查找与排序。没有索引能加速 “每组算完再比大小” 这个动作本身。
-
HAVING COUNT(*) > 5不会用上INDEX(user_id)，它得先把所有user_id分完组、计完数，才能比 - 调大
sort_buffer_size（MySQL）或work_mem（PG）只会让物化过程慢一点、落盘晚一点，但Rows_examined不变，OOM 风险照旧 - 真正有效的是把 HAVING 逻辑前置：比如把
HAVING COUNT(*) > 5改成先SELECT user_id FROM t GROUP BY user_id HAVING COUNT(*) > 5物化为临时表，再和其他表 JOIN —— 至少控制了中间集大小
最常被忽略的一点：HAVING 出现在视图里，等于把分组膨胀风险封装成了黑盒。你看到的是一个“表”，实际执行时却要拉起整张底表做聚合。删掉视图里的 HAVING，把聚合和过滤拆到外层查询，并确保 GROUP BY 字段有联合索引，才是可控的起点。
