SQL CTE是否物化取决于数据库优化器决策而非WITH语法；PostgreSQL默认常物化，MySQL倾向内联，SQL Server和Oracle依成本动态判断；引用多次、含不确定性函数或高开销操作时大概率物化。
SQL CTE 是否被物化，**不取决于你写了 WITH，而取决于数据库优化器怎么决定**。它既不是语法强制的，也不是所有数据库统一的行为——有的默认物化，有的默认内联，有的看情况动态选择。
不同数据库的默认倾向
PostgreSQL 默认较“激进”：即使 CTE 只引用一次，也常物化为临时结果集（尤其当逻辑较复杂时），可通过 NOT MATERIALIZED 显式关闭；
MySQL 8.0+ 默认倾向内联展开，除非 CTE 被多次引用、含递归或 UNION ALL，否则一般不物化；
SQL Server 和 Oracle 则根据成本估算动态判断：引用次数、数据量、函数不确定性、统计信息质量都会影响决策。
哪些情况大概率触发物化
- CTE 在查询中被引用两次或以上（比如 JOIN 自身、UNION 两边都用、WHERE 和 SELECT 中分别引用）
- CTE 包含不确定性函数（如 RANDOM()、NOW()、NEWID()），为保证语义一致，多数引擎会强制物化
- CTE 内部有高开销操作（大表聚合、多层 JOIN、窗口函数），优化器评估后认为缓存一次更划算
- 显式使用物化提示：PostgreSQL 12+ 支持 MATERIALIZED 关键字；Oracle 支持 /*+ MATERIALIZE */；SQL Server 可配合查询提示或跟踪标志干预
如何确认实际是否物化
不能靠猜，得看执行计划：
— PostgreSQL 中出现 CTE Scan 节点，通常表示物化；
— MySQL 的 EXPLAIN 输出若含 MATERIALIZE 或 DERIVED，说明已物化；
— SQL Server 若看到 Eager Spool 或独立子树先计算再复用，就是物化了；
— 还可以对比逻辑读：同一 CTE 引用两次，若基表扫描只发生一次，基本可判定物化成功。
要不要主动干预
多数简单查询无需干预，优化器能做好；但以下场景建议明确引导：
— 需要稳定结果（比如用了 RAND()），必须避免重复求值 → 加物化提示；
— 明知 CTE 很重、又被多次引用，但数据库没自动物化 → 主动加提示；
— 物化后性能反而变差（比如物化表太大、无索引、内存溢出）→ 尝试强制内联（如 PostgreSQL 的 NOT MATERIALIZED）。
