适合用cte替换的嵌套子查询有三类：同一子查询被引用2次及以上、不含外层表字段的非相关子查询、逻辑自成一体的独立子查询；反之硬套会导致执行计划变差或报错。

当嵌套子查询重复出现、逻辑可拆分、且不依赖外层表时，CTE 才值得替换；否则硬改只会让执行逻辑变模糊，甚至报错。

哪些嵌套子查询适合被 CTE 替换

CTE 不是万能解药，它只在特定结构下带来真实收益：

• 同一段 SELECT 逻辑在 FROM、WHERE、JOIN 中反复出现（比如 SELECT user_id FROM users WHERE status = 'active' 被用了三次）
• 子查询本身不包含相关子查询（correlated subquery），即没有类似 WHERE t2.created_at > t1.updated_at 这种跨层引用
• 子查询结果可独立计算，不随主查询每行动态变化
• 你想对某一层中间结果做调试——直接 SELECT * FROM cte_name 就能验证，而嵌套子查询做不到

哪些情况千万别硬套 CTE

强行替换反而埋坑：

• 子查询只用一次，且本身很短（比如 (SELECT MAX(id) FROM logs)），CTE 反而增加语法噪声
• 子查询含外层依赖，例如 WHERE order_date > (SELECT MIN(created_at) FROM users u WHERE u.id = o.user_id) —— 改成 CTE 后会报 ERROR: relation "o" does not exist
• 你在写 DELETE 或 UPDATE 语句：SQL Server 和 MySQL 都不支持 DELETE FROM t JOIN cte，必须退回到 IN 或 EXISTS 写法
• 需要物化中间结果（比如大表聚合后被多次 JOIN）：CTE 默认不物化，重复引用仍会重复扫描，不如显式建 CREATE TEMPORARY TABLE

CTE 定义顺序和引用限制必须守死

数据库按从上到下编译 CTE，不是所有“看起来能用”的写法都合法：

• 后一个 CTE 可以引用前面的，但不能反向（cte2 不能引用 cte3，哪怕你把它写在上面）
• 多个 CTE 用逗号分隔，最后一个不能加逗号，否则触发 syntax error near ","
• CTE 名字只在紧跟着的单条语句中有效，不能跨 UNION 分支，也不能在存储过程的后续语句里复用
• 如果 CTE 名和物理表同名（比如 WITH orders AS (...) SELECT * FROM orders），那这条语句里用的就是 CTE，不是原表——这点容易误判

最常被忽略的一点：CTE 的 ORDER BY 几乎总是危险操作。PostgreSQL 允许，但 MySQL 8.0 直接报错；即使允许，也不代表结果有序——除非配合 LIMIT，否则排序可能被优化器忽略。真要保序，得靠外层主查询的 ORDER BY。