能，但必须用括号包裹且子查询返回单值；多根节点需用UNION ALL或WITH递归；PRIOR位置错误会导致树倒置或无结果；WHERE在树生成后过滤，剪枝须用CONNECT BY条件；LEVEL分组需去重防重复计数。
START WITH 后面能直接跟子查询吗？
能，但必须用括号包裹，且子查询必须返回单值（或单列单行结果），否则 Oracle 会报 ORA-01427: single-row subquery returns more than one row。常见错误是误把多行 ID 列表塞进 START WITH，比如写成 START WITH id IN (SELECT id FROM roots) —— 这语法不合法，IN 不被支持。
正确做法是用子查询明确限定一个根节点，例如：
SELECT * FROM departments START WITH dept_id = (SELECT dept_id FROM departments WHERE dept_name = 'Executive') CONNECT BY PRIOR dept_id = parent_dept_id;
如果确实需要多个根节点，得改用 UNION ALL 拼接多个 START WITH 查询，或者换用 WITH 递归（Oracle 11gR2+）。
CONNECT BY 中的 PRIOR 位置搞反了，查出来全是空？
这是最常踩的坑：父子关系方向错，树就倒着长或根本连不上。关键看业务语义 —— PRIOR 总是指“上一级记录”的字段值。
- 向下查子树（常规用法）：当前行是子，上一行是父 →
CONNECT BY PRIOR parent_id = id（父的id等于当前的parent_id） - 向上查祖先：当前行是子，上一行是父 →
CONNECT BY PRIOR id = parent_id（当前的id等于上一行的parent_id）
混淆后典型现象是只返回根节点本身，或报 ORA-01788。建议在表里加注释说明字段含义，比如 parent_id 字段备注“指向直属上级部门的 dept_id”，避免靠猜。
WHERE 和 CONNECT BY 的执行顺序影响结果过滤
WHERE 是在整棵树生成完之后才生效的，不是边遍历边过滤。这意味着：如果某中间节点被 WHERE 条件排除，它的子节点依然会被连上来（只要路径没断）。
想真正“剪枝”，必须把条件挪到 CONNECT BY 里，或用 CONNECT_BY_ISLEAF / LEVEL 配合判断。例如：
-- ❌ 下面的 WHERE 不会阻止子节点被查出 SELECT * FROM employees START WITH manager_id IS NULL CONNECT BY PRIOR employee_id = manager_id WHERE salary > 5000; <p>-- ✅ 改用 CONNECT BY 中的 AND 来控制分支延伸 SELECT * FROM employees START WITH manager_id IS NULL CONNECT BY PRIOR employee_id = manager_id AND salary > 5000;
注意：后者中 salary > 5000 是对“当前行”生效的条件，所以只有满足该条件的节点才会被纳入树中，其子节点也才可能被继续展开。
嵌套查询 + LEVEL 导致分组统计出错？
当在 GROUP BY 中用 LEVEL，必须加 DISTINCT 或确保 LEVEL 在分组维度内唯一，否则聚合结果会重复计数。因为同一层级的节点可能出现在不同分支里，LEVEL 值相同但代表不同路径上的节点。
典型错误写法：
SELECT LEVEL, COUNT(*) FROM employees START WITH manager_id IS NULL CONNECT BY PRIOR employee_id = manager_id GROUP BY LEVEL; -- ❌ 可能多算
安全写法是显式去重，或用 SYS_CONNECT_BY_PATH 辅助识别唯一路径：
SELECT LEVEL, COUNT(DISTINCT employee_id) FROM employees START WITH manager_id IS NULL CONNECT BY PRIOR employee_id = manager_id GROUP BY LEVEL;
复杂点在于：一旦嵌套了子查询作为 START WITH 条件，又叠加多层 CONNECT BY，LEVEL 的语义仍只反映当前查询块内的深度，不会跨子查询继承。这点容易被忽略。
