结论：pl/sql中应避免手动循环递归查树，优先使用start with...connect by；prior方向须匹配业务流向，where过滤需嵌入connect by或预过滤，order siblings by保障层级排序，nocycle和level限制防范循环与性能风险。
直接说结论：别在 PL/SQL 里手动写循环递归查树——START WITH ... CONNECT BY 原生支持，性能远超 PL/SQL 自实现，且更安全、更简洁。
CONNECT BY PRIOR 的父子方向必须对齐业务流向
方向写反是 90% 的空结果或错乱数据的根源。不是“谁等于谁”，而是“从哪来、往哪去”：
- 查某部门的所有下级（自上而下）：
CONNECT BY PRIOR dept_id = parent_id✅ → 上一行的dept_id是当前行的parent_id，即“上一行是父，这一行是子” - 查某员工的所有上级（自下而上）：
CONNECT BY PRIOR manager_id = emp_id✅ → 当前行的emp_id是上一行的manager_id，即“上一行是子，这一行是父” -
CONNECT BY PRIOR parent_id = dept_id❌ —— 这其实是自下而上的逻辑，但若START WITH写的是根节点，就会查不到任何子树
WHERE 过滤不能放在语句末尾，否则子树被意外截断
把 WHERE status = 'ACTIVE' 放在 CONNECT BY 外面，Oracle 会先递归完整棵树，再过滤；中间某个节点被干掉，它下面所有子节点全丢，哪怕它们本身 status = 'ACTIVE'。
- 正确做法一（推荐）：把条件塞进
CONNECT BY子句：CONNECT BY PRIOR dept_id = parent_id AND status = 'ACTIVE'→ 注意：该条件只作用于子节点，根节点不受限（因为根由START WITH控制） - 正确做法二：用子查询预过滤源表：
SELECT * FROM (SELECT * FROM dept WHERE status = 'ACTIVE') d START WITH ... CONNECT BY ... - 错误示范：
... CONNECT BY ... WHERE status = 'ACTIVE'→ 子树消失风险极高
显示层级结构时，LEVEL 和 ORDER SIBLINGS BY 必须配合使用
LEVEL 只是深度编号，不控制顺序；不加 ORDER SIBLINGS BY，同级节点返回顺序不确定（按数据块物理顺序），每次执行可能不同。
- 缩进显示常用：
LPAD(' ', (LEVEL-1)*2) || dept_name，但注意：如果用了NOCYCLE，循环点之后的LEVEL不再增长，此时靠LEVEL判断层级关系会出错 - 稳定排序必须写：
ORDER SIBLINGS BY dept_name（同级升序）或ORDER SIBLINGS BY sort_order DESC -
ORDER BY LEVEL, dept_name❌ —— 这是全局排序，会打散父子嵌套结构，树就“扁平化”了
遇到循环引用或深树时，NOCYCLE 和 LEVEL 限制不能少
生产环境几乎必然存在脏数据或意外闭环，不加防护会导致 ORA-01436（connect by loop）或查询卡死。
- 强制启用循环检测：
CONNECT BY NOCYCLE PRIOR dept_id = parent_id，配合CONNECT_BY_ISCYCLE字段识别循环点 - 防深树爆炸：
WHERE LEVEL 放在 <code>CONNECT BY后、ORDER SIBLINGS BY前，可有效截断过深分支 ROWNUM 无效：它在递归完成之后才生效，无法限制递归过程本身- 真正要提速，优先考虑索引：
parent_id和id上建组合索引，比任何 SQL 技巧都管用
最易被忽略的一点：根节点的 PID 别用 NULL，尤其当表中存在多个根时。用 0 或 -1 显式标识，避免 START WITH parent_id IS NULL 触发全表扫描——这个细节在千万级数据上会让查询慢几秒到几十秒。
