PostgreSQL 的 WITH 子句不支持强制物化，MATERIALIZED 关键字在 15 前报错、16+ 仅语法兼容无实际效果；真正可控的中间结果缓存需用 TEMP TABLE、MATERIALIZED VIEW 或优化查询逻辑。
PostgreSQL 没有“Materialized CTE”这个东西，WITH 子句本身不支持强制物化（即把中间结果固化到临时内存/磁盘）；盲目加 MATERIALIZED 关键字会报错或被忽略。
为什么你搜不到 MATERIALIZED 在 WITH 里生效
PostgreSQL 的 WITH 默认是“inline 展开”行为：优化器有权决定是否物化、何时物化、甚至完全重写逻辑。它不像 Oracle 的 MATERIALIZE 提示或 SQL Server 的 OPTION (USE HINT('ENABLE_QUERY_OPTIMIZER_HOTFIXES')) 那样提供显式物化控制。
常见误解来源：
- 把 Oracle 的
/*+ MATERIALIZE */注释误套用到 PostgreSQL - 看到某些博客写
WITH MATERIALIZED cte AS (...) SELECT ...—— 这在 PostgreSQL 15 之前语法错误，16+ 也仅支持MATERIALIZED作为可选关键字（无实际效果），不是功能开关 - 混淆了
TEMP TABLE或CREATE MATERIALIZED VIEW的语义
真正能“强制缓存中间结果”的替代方案
当嵌套查询反复计算同一子集（比如多处引用聚合结果、多次 JOIN 同一过滤集），且 EXPLAIN ANALYZE 显示该部分重复执行、耗时占比高时，才需要干预。可行路径只有三条：
-
CREATE TEMP TABLE AS SELECT ...：显式落盘，后续查询直接FROM temp_table；适合单会话内复用，自动在会话结束时销毁 -
CREATE MATERIALIZED VIEW AS SELECT ...：持久化存储，需手动REFRESH MATERIALIZED VIEW CONCURRENTLY；适合跨会话、跨事务共享，但要确保基表有唯一索引（否则CONCURRENTLY失败） - 用
WITH RECURSIVE+ 显式去重逻辑模拟“缓存”：仅适用于树形或迭代场景，不能通用
别指望 WITH 自己扛住 10GB 中间结果——它没内存预留机制，work_mem 超限就自动落盘排序/哈希，性能反而更差。
什么时候该放弃“缓存中间结果”，转而优化原始逻辑
多数所谓“复杂嵌套”，其实根本不需要缓存，而是写法拖累了优化器。先检查这几个信号：
-
EXPLAIN ANALYZE里出现多个SubPlan节点，且每个都标着(actual time=... rows=...)重复值 → 真的在反复执行 - 外层
WHERE条件没下推到子查询里，导致子查询返回百万行，再在外层FILTER→ 改成JOIN或把条件挪进子查询WHERE - 子查询含
ORDER BY ... LIMIT 1却被用于SELECT列 → 改用DISTINCT ON或窗口函数ROW_NUMBER() OVER (...) = 1 - 多个
UNNEST套LATERAL但数组长度不一致 → 触发笛卡尔积，行数爆炸，看起来像“慢”，实则是数据膨胀
最常被忽略的一点：物化中间结果只是把计算成本从查询时移到了刷新时。如果业务要求强一致、低延迟，或者基表更新频繁，那 REFRESH 本身就成了瓶颈——此时加索引、重写为 JOIN、拆成应用层分步查，往往比硬上物化更稳。
