PostgreSQL中WITH RECURSIVE无硬编码深度限制，但受statement_timeout和work_mem制约；常见错误为栈溢出或超时中断；建议设statement_timeout并确保递归有显式终止条件。
PostgreSQL 里 WITH RECURSIVE 默认有深度限制吗？
没有硬编码的默认深度上限，但实际受 statement_timeout 和栈内存（work_mem）制约。递归层级过高时，常见报错是 ERROR: stack depth limit exceeded 或查询被超时中断。
实操建议：
- 用
SET statement_timeout = '30s'控制整体耗时，比盲目调高栈更安全 - 递归子句中必须包含显式终止条件（如
depth ），不能只依赖数据自然结束 -
work_mem过小会导致中间结果频繁落盘，反而拖慢深层递归；建议单次查询设为4MB起步（通过SET LOCAL work_mem = '4MB'）
Oracle 的 CONNECT BY 怎么防无限循环？
Oracle 不靠深度计数器，而是依赖 CONNECT_BY_ISCYCLE 和 NOCYCLE 关键字做运行时环检测。没加 NOCYCLE 时，遇到环直接报错 ORA-01436: CONNECT BY loop in user data。
实操建议：
- 必须写
CONNECT BY NOCYCLE才能继续执行，否则一碰到自引用或双向关系就崩 -
CONNECT_BY_ISCYCLE是伪列，值为1表示当前行触发了环，可用来过滤或标记异常路径 - Oracle 没有类似 PostgreSQL 的
MAX_RECURSION_DEPTH参数，深度由数据本身和LEVEL限制（比如WHERE LEVEL ）
两个数据库对「同一份树形数据」递归结果不一致？
核心差异在遍历顺序和环处理逻辑：PostgreSQL 的 WITH RECURSIVE 是标准 DFS（深度优先），而 Oracle 的 CONNECT BY 默认是“从根开始逐层展开”的伪 BFS（实际是按 ORDER SIBLINGS BY 排序后输出）。
实操建议：
- PostgreSQL 中若要模拟 Oracle 的层级展开效果，得在递归 CTE 外套一层
ORDER BY depth, ...，并用ROW_NUMBER() OVER (PARTITION BY depth ORDER BY ...)控制兄弟节点顺序 - Oracle 中若要真正 DFS，只能靠
ORDER SIBLINGS BY配合函数构造“深度优先”的排序键（例如拼接路径字符串） - 两边都用路径字符串（如
/1/5/23/）记录访问轨迹，比单纯依赖LEVEL或depth更可靠
为什么加了 MAX_RECURSION_DEPTH 还报错？
因为 PostgreSQL 根本没有这个配置项——这是 SQL Server 的参数，误用会导致语法错误 ERROR: syntax error at or near "MAX_RECURSION_DEPTH"。Oracle 也没有对应概念。
实操建议：
- PostgreSQL 唯一可控的“深度防护”是手动加
WHERE depth 到递归成员中，且 <code>depth必须在初始查询和递归查询里都定义好 - Oracle 必须用
LEVEL 放在 <code>WHERE子句（注意不是CONNECT BY条件里），否则无效 - 两者都不检查“逻辑环”，只管层数或路径是否重复；真实业务中，父子关系脏数据（比如 A→B→A）仍需额外校验
递归查询真正难的不是写法，而是想清楚：你到底要的是路径枚举、可达性判断，还是带聚合的层级统计。选错模型，再调参数也救不回语义偏差。
