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 字段有联合索引，才是可控的起点。