有本质区别：现代数据库通常生成相似执行计划，但CTE可被强制物化而子查询永不物化；递归查询、多处引用、绕过嵌套限制等场景必须用CTE，而简单过滤用CTE反而可能因谓词下推失效导致性能下降。
CTE 和子查询在执行计划里真有区别吗
没有本质区别。现代主流数据库（PostgreSQL 12+、SQL Server 2019+、MySQL 8.0+）对 WITH CTE 和内联子查询通常生成几乎相同的执行计划，优化器会自动展开或重用，不强制物化。但有两个例外：MATERIALIZED（PostgreSQL）或 /*+ MATERIALIZE */（Oracle）提示可强制物化 CTE，此时它变成临时结果集，可能拖慢小数据量查询；而子查询永远不被物化——这点容易被误认为“CTE 更高效”，其实恰恰相反。
什么时候必须用 CTE 而不能用子查询
递归查询是硬性需求场景，子查询无法替代：
-
WITH RECURSIVE t AS (SELECT ... UNION ALL SELECT ... FROM t ...)是唯一标准写法，用于组织架构树、BOM 展开、路径遍历等 - 多个引用同一逻辑块时（比如主查询 +
ORDER BY子句都依赖相同计算），CTE 避免重复写，也避免子查询嵌套过深导致可读性崩溃 - 某些数据库（如 SQL Server）对子查询嵌套层级有限制（默认 32 层），CTE 可绕过该限制
哪些子查询写法会让 CTE 反而更慢
盲目把简单过滤提取成 CTE 往往适得其反：
- 单层
WHERE过滤：比如SELECT * FROM (SELECT id, name FROM users WHERE status = 'active') t换成 CTE 后，优化器可能放弃下推谓词，导致全表扫描后再过滤 - CTE 中含非 SARGable 表达式（如
UPPER(name) = 'JOHN'），且未加函数索引，而子查询中直接写字段比较能命中索引 - MySQL 8.0 之前 CTE 默认强制物化，哪怕只引用一次，也会写磁盘临时表；升级后仍需检查
EXPLAIN FORMAT=TREE确认是否被展开
生产环境上线前必须验证的三点
别只看语法对不对，重点看执行行为是否符合预期：
- 用
EXPLAIN ANALYZE（PostgreSQL）、SET STATISTICS PROFILE ON（SQL Server）或EXPLAIN FORMAT=TREE（MySQL 8.0+）对比 CTE 版本和等价子查询版本的实际执行计划，关注Actual Rows和Buffers差异 - 确认 CTE 是否被多次引用——如果只用一次，又没递归/命名需要，大概率子查询更轻量
- 检查目标数据库版本对 CTE 的实现细节：比如 PostgreSQL 12 支持
MATERIALIZED / NOT MATERIALIZED显式控制，而旧版只能靠优化器猜
CTE 不是性能银弹，它是逻辑组织工具；子查询不是过时写法，而是最贴近执行引擎的原始表达。真正影响性能的是谓词位置、索引覆盖和统计信息准确性，而不是你写了 WITH 还是写了括号。
