物化子查询是postgresql优化器自动选择的执行策略，不可手动开关；其性能取决于子查询效率、索引覆盖及work_mem设置，误用反而拖慢查询。
物化子查询（Materialized Subquery）不是 PostgreSQL 的显式语法特性，而是优化器在特定条件下自动触发的执行策略——它本身不可手动开启或关闭，但你可以通过结构设计和参数控制来影响其是否发生。直接写 MATERIALIZED 关键字只在 LATERAL 或 CTE 中有条件生效，且仅限于 PostgreSQL 12+；PostgreSQL 16 并未新增强制物化语法，误以为加个提示就能“让子查询先算完”是常见误解。
为什么 EXPLAIN 显示 Materialize 却没提速？
当你在 EXPLAIN ANALYZE 输出里看到 Materialize 节点（例如在 Hash Join 的内表侧），说明优化器判断：把子查询结果暂存内存/临时磁盘比反复执行更便宜。但这不等于性能变好——如果子查询本身低效、返回行数巨大、或 work_mem 不足导致落盘，Materialize 反而会拖慢整体耗时。
- 典型错误现象：
Materialize节点下actual time占总耗时 90% 以上，且Buffers: temp read/write数值高 - 根本原因：子查询未被索引覆盖、含非SARGable表达式（如
upper(name) = 'ABC'）、或外层 JOIN 条件无法下推 - PostgreSQL 16 的变化：JIT 编译默认启用，但对物化过程无加速作用；反而若
jit_above_cost设置过低，可能让小结果集也触发 JIT，增加编译开销
用 WITH RECURSIVE 或 MATERIALIZED CTE 强制物化？
PostgreSQL 16 不支持 MATERIALIZED 修饰符用于普通 CTE（即 WITH cte AS MATERIALIZED (SELECT ...) 是无效语法）。唯一可控的物化方式是使用 WITH cte AS NOT MATERIALIZED 去**禁止**物化——这反而常被用来调试：对比物化 vs 非物化路径的实际开销。
- 正确写法（仅 PostgreSQL 12+ 支持）：
WITH cte AS MATERIALIZED (SELECT ...)—— 错！该语法在 16 中仍报错syntax error at or near "MATERIALIZED" - 可行替代：
WITH cte AS (SELECT ...)+ 确保外层引用至少两次，优化器才可能选择物化；若只引用一次，大概率直接内联 - 真实约束：
cte必须是无副作用的纯 SELECT，不能含random()、now()等易变函数，否则优化器拒绝物化
真正能规避慢查询的替代方案
与其纠结物化是否发生，不如直接替换掉易引发物化的低效结构。以下操作经 PostgreSQL 16 生产验证有效：
- 把关联子查询改写为
LEFT JOIN LATERAL (SELECT ... LIMIT 1)，避免优化器被迫物化整个中间结果集 - 对高频使用的子查询逻辑，创建物化视图（
CREATE MATERIALIZED VIEW），并配合REFRESH CONCURRENTLY减少锁表时间 - 检查
work_mem：若物化节点频繁出现temp read=xxx，说明内存不足溢出到磁盘，可临时调高（如从 4MB → 32MB），但需注意全局连接数乘积不能超物理内存 - 禁用自动物化的极端手段：
SET enable_material = off，适用于已知子查询结果集小且外层只引用一次的场景，可避免无谓的内存拷贝
物化行为本质是优化器的成本权衡结果，不是性能开关。最常被忽略的一点是：统计信息过期会让优化器误判子查询行数，导致本不该物化的地方强行物化，或该物化时却选择嵌套循环。执行 ANALYZE table_name 比调任何参数都管用。
