正确写法是：START WITH 根节点条件（如 parent_id IS NULL），CONNECT BY PRIOR parent_id = child_id；注意 PRIOR 必须放在父字段前，LEVEL 从1开始且需 ORDER SIBLINGS BY 排序，缩进用 LPAD(' ', (LEVEL-1)*2) || name。
START WITH + CONNECT BY 语句怎么写才不出错
pl/sql 里查树形结构，start with 和 connect by 是唯一直接支持递归的原生方式。但一写就报 ora-01436: connect by loop in user data 或结果重复、漏层，往往不是数据问题，而是没理清“谁连谁”和“从哪开始”。
关键判断：必须明确根节点条件（START WITH），再定义父子关系（CONNECT BY PRIOR child_id = parent_id —— 注意 PRIOR 放在**父字段前**，这是最容易反着写的坑）。
-
START WITH后面只能是布尔表达式，不能是子查询（除非用 WITH 子句预处理） - 如果表里有多个根（比如
parent_id IS NULL的记录不止一条），START WITH parent_id IS NULL会启动多个独立树遍历，结果按深度优先拼一起，不是“一棵大树” - 别在
WHERE里过滤中间节点（比如WHERE status = 'ACTIVE'），它会在递归完成后才过滤，导致子树被意外截断；要用CONNECT BY条件里嵌套判断，或改用子查询过滤源数据
如何安全加层级序号和缩进显示
单纯查出父子关系不够，业务常要展示层级（第几级）、缩进、路径。Oracle 提供了几个伪列，但用错就乱序或越界。
LEVEL 是最常用也最易误用的：它从 1 开始计数，根为 1，每下一层 +1；但它**不保证输出顺序**，必须显式 ORDER SIBLINGS BY 才能按兄弟节点排序。缩进靠 LPAD(' ', (LEVEL-1)*2) || name 实现，但注意 LEVEL 在 WHERE 子句不可用（会报 ORA-01788），只能在 SELECT 或 ORDER BY 中用。
- 想限制只查到第 3 层？用
AND LEVEL 写在 <code>CONNECT BY条件里，别放WHERE -
SYS_CONNECT_BY_PATH(name, '/')可生成路径，但字段超长会报ORA-01489，建议提前SUBSTR(..., 1, 4000) - 如果节点名含斜杠 /，
SYS_CONNECT_BY_PATH会混淆路径分隔，此时应换用自定义分隔符，比如SYS_CONNECT_BY_PATH(name, '→')
循环引用检测与避免死循环
ORA-01436 不代表数据一定坏了，可能是父子关系配置反了（比如 A 的 parent_id 指向 B，B 的 parent_id 又指回 A），也可能是 PRIOR 位置写反导致逻辑循环。
Oracle 默认不检查循环，得手动加 NOCYCLE 并配合 CONNECT_BY_ISCYCLE 伪列识别。但开了 NOCYCLE 后，循环分支会被截断，且 LEVEL 在循环点后不再增长 —— 这意味着你看到的“第5层”可能其实是第2层绕回来的。
- 加
NOCYCLE是必须的，尤其面对用户可编辑的组织架构表 -
CONNECT_BY_ISCYCLE = 1表示当前行是循环入口点（即它的 parent_id 指向了自己祖先），不是所有循环节点都标 1 - 不要依赖
LEVEL做深度限制 +NOCYCLE组合来“防卡死”，它不阻止递归展开，只是标记；真怕性能崩，得加LEVEL 硬限制
替代方案：什么时候该放弃 CONNECT BY
当树超过几千节点、层级深于 10 层、或需要频繁修改父子关系时，CONNECT BY 性能会断崖下跌，执行计划常出现大量 BUFFER SORT 和 CONNECT BY PUMP，且无法走普通索引（只能靠函数索引或物化路径）。
更稳的选择是预计算路径（如 path VARCHAR2(2000) 存 “/1/5/23/”），或用 Oracle 12c+ 的 WITH RECURSIVE（需开启兼容模式）。但注意：WITH RECURSIVE 在 PL/SQL 块里不能直接用，得封装成视图或函数。
- 已有老系统用
CONNECT BY，别急着重写；但新模块涉及高频树操作，优先设计物化路径或闭包表 -
CONNECT BY不支持跨 schema 关联递归（比如父表在 A 用户下，子表在 B 用户下），这时必须用 WITH 或程序层拼装 - 调试时别只看 SQL*Plus 输出，用
EXPLAIN PLAN看是否走了CONNECT BY PUMP，它意味着全表扫描式递归，没索引加速
真正难的不是写出语法正确的 CONNECT BY，而是想清楚：这棵树的根是不是稳定、环是不是允许、层级深度有没有业务上限、以及——它到底需不需要实时递归。
