适合用WITH替换的嵌套子查询需同时满足：被多处引用、不依赖外层字段、逻辑自包含；硬改单次使用的相关子查询反而降低性能或引发错误。
能重构，但必须分清哪些嵌套子查询适合改、哪些硬改反而出错。CTE不是万能语法糖，它在 PostgreSQL 15 中的行为有明确边界：默认物化、作用域严格、依赖顺序敏感。盲目替换三层嵌套，可能让查询变慢、报错或逻辑错位。
哪些嵌套子查询适合用 WITH 替换？
只推荐用于满足全部三个条件的子查询：
- 被主查询
FROM、JOIN、WHERE多处引用（比如同一段SELECT user_id FROM users WHERE status = 'active'出现 ≥2 次） - 不依赖外层表字段（即不能含
WHERE order_date > t1.created_at这类相关子查询） - 逻辑自包含、可独立验证（例如纯聚合、纯过滤、纯 JOIN，不混写 ORDER BY + LIMIT 以外的排序）
常见误用：把 SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'CN') 硬改成 CTE——它只用一次，且无重复计算开销，改了反而多一次物化 I/O。
为什么加了 WITH 反而报 ERROR: relation "t" does not exist？
这是最典型的范围误解。CTE 名字只在紧随其后的单条主查询中有效，不能跨以下任一场景：
- UNION / UNION ALL 的不同分支（
WITH t AS (...) SELECT * FROM t UNION SELECT * FROM t❌，第二个t不可见） - 存储过程或函数里的多个独立 SQL 语句（CTE 不是变量，不能“存起来”下一句再用）
- 复制粘贴到新查询窗口单独执行（
SELECT * FROM filtered_logs会报错，必须连同WITH filtered_logs AS (...)一起运行）
调试时想看中间结果？直接把主查询换成 SELECT * FROM cte_name，但务必保证整条 WITH ... SELECT 在一个语句块里。
性能没提升甚至更慢，怎么查原因？
PostgreSQL 15 默认将 CTE 视为物化节点，这意味着：
- 即使你写了两次
SELECT * FROM cte_name，执行计划里仍可能出现两次CTE Scan（而非一次计算、两次读取） - 物化会触发临时磁盘写入，对大结果集反而拖慢整体响应
- 优化器无法把 CTE 内部谓词下推到基表扫描层，可能错过索引
实操建议：
- 先跑
EXPLAIN (ANALYZE, BUFFERS)，对比改写前后Seq Scan行数、Temp Read/Write量 - 若某 CTE 计算昂贵且被多次引用，考虑显式建
CREATE TEMP TABLE并在关键列上加索引 - 需要强制物化（避免重复计算），可用
/*+ Materialize(cte_name) */提示（需启用pg_hint_plan扩展）
多个 CTE 怎么组织才不容易乱？
核心是模拟函数拆分思维，每层只做一件事：
- 命名用业务语义，如
recent_orders、high_value_customers，禁用t1、tmp - CTE 之间用空行分隔，比写
-- filter active users更直观 - 定义顺序 = 执行依赖顺序：后一个 CTE 可引用前一个，但不能反向（
WITH a AS (...), b AS (SELECT * FROM a)✅；WITH b AS (SELECT * FROM a), a AS (...)❌） - 多个 CTE 用逗号分隔，最后一个不加逗号，否则报
syntax error near ","
递归 CTE 是特例，必须加 RECURSIVE 关键字，且初始查询和递归查询之间用 UNION ALL 连接——漏掉任一要素都会直接报错，不是逻辑问题而是语法拒绝执行。
