不能直接替代；SQL标准中仅WITH RECURSIVE支持树形遍历，子查询无法表达自引用逻辑，仅在层级≤3层且固定时可有限模拟，深度未知时必须用递归CTE。
子查询真能替代递归查询吗？先说结论
不能直接替代。SQL 标准中，WITH RECURSIVE 是唯一规范支持树形/层级遍历的机制；普通子查询无法表达“自身调用自身”的逻辑，强行用多层嵌套子查询模拟递归，只会让查询变慢、内存更高、可读性崩坏。所谓“用子查询降低内存”，其实是误把「非递归的层级展开」当成了「递归替代」。
什么场景下可以用子查询“绕开”递归？
适用于层级深度**固定且极小**（通常 ≤ 3 层）、且父级关系明确可枚举的场景，比如：查某员工的直属上级、上级的上级、再上一级——共最多三代。这时用 JOIN 或相关子查询比启动递归 CTE 更轻量。
- 适用：
SELECT e1.name, e2.name AS mgr1, e3.name AS mgr2 FROM employees e1 LEFT JOIN employees e2 ON e1.mgr_id = e2.id LEFT JOIN employees e3 ON e2.mgr_id = e3.id WHERE e1.id = 123 - 不适用：查“所有下属（含间接）”，或组织树深度未知——此时子查询必须写成 5 层嵌套 +
UNION ALL拼接，实际执行计划更耗内存 - 注意：
IN (SELECT ...)类子查询若返回大量 ID，在 MySQL 5.7 或旧版 PostgreSQL 中可能触发临时表 + 文件排序，反而比递归 CTE 更吃内存
递归 CTE 内存高的真正原因和缓解点
内存压力主要来自递归中间结果集累积（尤其未加限制时），不是“用了递归”本身。优化方向是控制递归范围，而非消灭递归语法：
- 务必在
WHERE子句中对递归锚点（anchor）和递归成员（recursive term）加过滤，例如：WHERE level 或 <code>AND parent_id IS NOT NULL - PostgreSQL 中启用
work_mem调优，但别盲目调大；MySQL 8.0+ 的递归默认有cte_max_recursion_depth限制（默认 1000），超限直接报错ERROR 3636，避免无限膨胀 - 避免在递归分支中
SELECT *；只取必要字段，尤其是不要带大文本/BLOB 列进入递归集
当真要“降内存”，优先考虑应用层分批拉取
如果层级数据量大（如百万级节点的图谱），SQL 层硬扛递归本身就是反模式。更可行的做法是：
- 在应用代码里用 BFS/DFS 迭代查询，每次只查一层（例如：先查 ID=100 的直系子节点，再用这批 ID 查下一层），配合
IN (id1, id2, ...)和合理LIMIT - 预计算路径字段（如
path VARCHAR(512)存'/1/100/105/108'），用字符串前缀匹配替代递归（WHERE path LIKE '/1/100/%'） - 数据库外建索引表（如
ancestor_descendant），用空间换查询时间，彻底规避运行时递归
递归查询不是洪水猛兽，滥用才是问题。把“降低内存”等同于“不用递归”，就像把“减少油耗”理解成“拆掉发动机”——关键在怎么用，不在删掉它。
