PRIOR必须放在“上一层”字段前，方向决定查询路径：自上而下查子孙用CONNECT BY PRIOR parent_id = child_id，自下而上查祖先用CONNECT BY PRIOR child_id = parent_id。
CONNECT BY PRIOR 的父子方向怎么写才对
写反是最常见的错误，直接导致查不出数据或结果错乱。prior 必须放在「上一层」的字段前，不是“谁等于谁”，而是“**从哪来、往哪去**”。
比如要查某个部门的所有下级部门（自上而下）：
-
CONNECT BY PRIOR dept_id = parent_dept_id✅ 正确：当前行的parent_dept_id等于上一行的dept_id，即“上一行是父，这一行是子” -
CONNECT BY PRIOR parent_dept_id = dept_id❌ 错误：这会变成自下而上查祖先，但START WITH又设的是根节点，逻辑冲突
再比如查某员工的所有上级（自下而上），才该用：CONNECT BY PRIOR manager_id = emp_id —— 当前行的 emp_id 是上一行的 manager_id。
WHERE 过滤放错位置会导致子树被截断
把 WHERE status = 'ACTIVE' 写在 CONNECT BY 之后、整个语句末尾，Oracle 会先递归完所有节点，再统一过滤。结果就是：某个中间节点被 WHERE 干掉后，它下面的整棵子树就消失了，哪怕那些子节点本身 status = 'ACTIVE'。
正确做法只有两个：
- 把条件挪进
CONNECT BY：例如CONNECT BY PRIOR dept_id = parent_dept_id AND status = 'ACTIVE'（注意：这个条件只作用于子节点，不影响根节点） - 或者提前用子查询过滤源表：
SELECT * FROM (SELECT * FROM dept WHERE status = 'ACTIVE') d START WITH ... CONNECT BY ...
别信“加个 AND ROWNUM 就能提速”——<code>ROWNUM 在递归完成前不生效，它截的是最终结果集，不是递归过程。
LEVEL 和 ORDER SIBLINGS BY 不是一回事
LEVEL 是伪列，表示当前行在树中的深度（根为 1），但它不控制显示顺序。如果你看到层级混乱，不是 LEVEL 没用对，而是没用 ORDER SIBLINGS BY。
ORDER BY 是全局排序，会打散树形结构；ORDER SIBLINGS BY 才是每个层级内部按指定字段排序：
-
ORDER SIBLINGS BY dept_name→ 同一级的部门按名称升序排 -
ORDER SIBLINGS BY dept_id DESC→ 同一级按 ID 降序 - 不写这个子句时，Oracle 按数据块物理顺序返回，每次执行可能不同
缩进显示常用 LPAD(' ', (LEVEL-1)*2) || dept_name，但注意：如果用了 NOCYCLE，循环点之后的 LEVEL 不再增长，你看到的 “LEVEL = 5” 可能实际是第二层绕回来的，这时候靠 LEVEL 做业务判断会出错。
SYS_CONNECT_BY_PATH 超长报 ORA-01489 怎么办
SYS_CONNECT_BY_PATH(name, '/') 很方便，但 Oracle 默认限制路径长度为 4000 字节（字符集影响实际字数）。一旦超限，直接报 ORA-01489: result of string concatenation is too long，且无法用 TO_CHAR 或 CAST 规避。
稳妥做法是在拼接前主动截断：
-
SYS_CONNECT_BY_PATH(SUBSTR(name, 1, 200), '/')—— 先压窄单个节点名 - 或在外层再套一次
SUBSTR(..., 1, 4000)，但要注意：路径里含多字节字符时，SUBSTR按字符数截，不是字节数，仍可能超 - 真正保险的方式是改用
LISTAGG+ 分层子查询（Oracle 11gR2+），不过那就脱离了CONNECT BY原生路径能力
还有个隐藏坑：SYS_CONNECT_BY_PATH 对空值（NULL）敏感，只要任意一个 name 是 NULL，整条路径就变 NULL —— 记得用 NVL(name, '(unknown)') 防御。
