oracle中start with ... connect by查询快是因为原生支持层次查询，执行计划使用connect by pump算子，避免自连接或临时表开销；parent_id等字段建议建索引以防全表扫描；需注意prior位置防止笛卡尔积或无限循环。
Oracle里START WITH ... CONNECT BY为什么查得快
因为它是Oracle原生支持的层次查询语法，执行计划会走CONNECT BY PUMP算子，避免了自连接或临时表的开销。它不依赖索引也能较快定位层级关系，但前提是CONNECT BY条件中涉及的字段（比如PARENT_ID）最好有索引——否则在大数据量下仍可能全表扫描。
常见错误是写成CONNECT BY PRIOR ID = PARENT_ID却忘了PRIOR位置，导致查出笛卡尔积或无限循环；正确顺序是“父找子”用PRIOR PARENT_ID = ID，“子找父”才用PRIOR ID = PARENT_ID。
实操建议：
- 始终显式指定
START WITH的根节点条件，不要依赖默认行为 - 用
LEVEL限制深度，比如WHERE LEVEL ，防止意外的深层递归拖垮性能 - 若需排序，优先用
ORDER SIBLINGS BY而非ORDER BY，前者只对同级节点排序，开销小得多
怎么避免CONNECT BY死循环
死循环通常由数据异常引起：某个节点的PARENT_ID指向自己、或形成环（A→B→C→A）。Oracle默认不检测环，只会报错ORA-01436: CONNECT BY loop in user data，但这个报错发生在遍历完成之后，已消耗大量资源。
解决方法是在语句开头加NOCYCLE，并配合CONNECT_BY_ISCYCLE伪列识别问题节点：
SELECT ID, NAME, LEVEL, CONNECT_BY_ISCYCLE FROM ORG_TREE START WITH PARENT_ID IS NULL CONNECT BY NOCYCLE PRIOR ID = PARENT_ID
这样即使存在环，查询也能返回结果，且CONNECT_BY_ISCYCLE = 1的行就是问题所在。上线前务必用该方式抽检数据完整性。
CONNECT BY和WITH RECURSIVE能混用吗
不能。Oracle 12c+虽支持WITH RECURSIVE（SQL:2008标准），但它和START WITH ... CONNECT BY是两套独立机制，语法、语义、优化器路径都不同。强行混用会直接报错ORA-32033: unsupported column aliasing或类似解析失败提示。
选择依据很实际：
- 维护老系统、需要
LEVEL、SIBLINGS、ISLEAF等专有伪列 → 用CONNECT BY - 要跨数据库兼容（如迁移到PostgreSQL/SQL Server）→ 用
WITH RECURSIVE - 递归逻辑复杂，需多分支判断或中间计算 →
WITH RECURSIVE更易读，但Oracle下性能通常略逊于CONNECT BY
为什么CONNECT BY结果里ROWNUM不准
因为ROWNUM在CONNECT BY执行过程中就已分配，不是最终结果集的序号。例如WHERE ROWNUM 会截断中间某层的部分节点，导致树形结构不完整——你可能只拿到根和第一层的几个子节点，第二层一个都看不到。
正确做法是用分析函数包裹：
SELECT * FROM (
SELECT ID, NAME, LEVEL,
ROW_NUMBER() OVER (ORDER BY LEVEL, ID) RN
FROM ORG_TREE
START WITH PARENT_ID IS NULL
CONNECT BY PRIOR ID = PARENT_ID
)
WHERE RN <p>注意：<code>ORDER BY</code>必须明确，否则<code>ROW_NUMBER()</code>顺序不可控；如果只要第一页，这个写法没问题；但做分页时（比如查第11–20条），<code>ROW_NUMBER()</code>比<code>OFFSET ... FETCH</code>更稳妥，因为后者在层次查询中可能跳过整棵子树。</p><p>真正麻烦的是带聚合的树查询——比如统计每层节点数，这时<code>CONNECT BY</code>的执行顺序和聚合时机容易错位，得靠<code>MODEL</code>子句或拆成两步走。这点常被忽略，一上生产就出数据偏差。</p>
