适合用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。
