Oracle存储过程需用游标执行START WITH CONNECT BY；方向易错，PRIOR在左向上找、在右向下找；必须加NOCYCLE防环，注意事务一致性与数据状态。
Oracle 存储过程中用 START WITH CONNECT BY 必须写成游标查询
直接在 pl/sql 块里写 select ... start with connect by 不会报错，但你拿不到结果——因为 pl/sql 不支持直接执行带层次查询的 sql 语句并赋值给变量。必须通过显式游标或隐式游标循环遍历。
常见错误现象：PLS-00428: an INTO clause is expected in this SELECT statement，尤其当你试图用 SELECT ... INTO 时；或者看似执行成功，但 BULK COLLECT 没拿到数据，其实是语法没对上上下文。
- 用
FOR rec IN (SELECT ... START WITH CONNECT BY)最安全，自动处理单行/多行 - 如果要存到集合里再处理，用
BULK COLLECT INTO，但注意：必须配合OPEN/FETCH/CLOSE或用FOR隐式游标 -
CONNECT BY的起始条件（START WITH）建议用确定字段，比如parent_id IS NULL或具体 ID，避免运行时动态计算出空集
CONNECT BY PRIOR 的方向别写反：父→子还是子→父？
这是最容易翻车的地方。Oracle 默认按“当前行 → 父行”找，所以 PRIOR 放在哪边，决定了遍历方向。
例如表 t_menu(id, parent_id, name)，想从根节点查所有后代：
SELECT id, parent_id, name FROM t_menu START WITH parent_id IS NULL CONNECT BY PRIOR id = parent_id;
这里 PRIOR id = parent_id 表示：上一层的 id 是当前层的 parent_id，即“由父找子”。如果写成 id = PRIOR parent_id，就变成“由子找父”，结果是向上追溯祖先，不是树形展开。
- 记住口诀：“PRIOR 在左，往上找；PRIOR 在右，往下找”（指等号左侧是否带 PRIOR）
- 在存储过程中拼接动态 SQL 时，这个等式方向极易因变量替换错位，建议先在 SQL*Plus 里验证好再搬进过程
- Oracle 10g+ 支持
CONNECT_BY_ROOT和LEVEL，调试时加LEVEL能一眼看出深度是否异常
递归太深导致 ORA-01436: CONNECT BY loop in user data
这不是代码写错了，而是数据本身有环（比如 A→B→C→A），CONNECT BY 检测到循环就中断。存储过程里不捕获的话，整个过程直接报错退出。
真实场景中，权限树、组织架构表偶尔会出现配置错误导致闭环，不能只靠前端校验。
- 加
NOCYCLE是必须的：CONNECT BY NOCYCLE PRIOR id = parent_id - 加了
NOCYCLE后，可用CONNECT_BY_ISCYCLE字段识别出哪条记录触发了环（值为 1） - 性能影响：有环检测会略微拖慢，但比崩掉强；如果确认数据绝对无环，可去掉
NOCYCLE省点开销 - 别依赖
MAXDEPTH（Oracle 12c+ 才支持），老系统得靠LEVEL <= N截断，否则可能栈溢出
在存储过程中修改树结构后立即查询，结果不一致？
比如刚执行完 UPDATE t_menu SET parent_id = ...，紧接着用 START WITH CONNECT BY 查，发现路径没变——不是缓存问题，是事务隔离级别和查询时机问题。
Oracle 默认 READ COMMITTED，但你在同一个事务里改完还没 COMMIT，后续查询能看到新数据；可如果用了自治事务（AUTONOMOUS_TRANSACTION）去更新，那主事务里的查询就看不到它，除非也提交。
- 确保树结构 DML 和层次查询在同一个事务上下文中，不要无意中拆到不同自治事务里
- 调试时用
DBMS_OUTPUT.PUT_LINE打印刚更新的id和parent_id，再手动查一遍，确认数据确实落库了 - 如果必须跨事务查，考虑加
FOR UPDATE或显式COMMIT，但要注意锁等待和一致性风险
树形遍历真正麻烦的从来不是语法，而是数据状态、事务边界和循环隐含的业务约束。写完别急着交，用几条典型路径（根、叶子、中间断链、人为造环）跑一遍实际数据。
