sql server中用递归cte查树形结构最可靠：必须用union all连接锚点与递归成员，严格字段顺序，显式设option (maxrecursion n)防超限，且parentid需建索引保障性能。
SQL Server 里用 CTE 实现树形查询最可靠
SQL Server 不支持存储过程直接递归调用自身（即 EXEC @proc_name 在过程中再调自己），强行模拟容易栈溢出或逻辑失控。真正稳定查树形结构的方式是用递归 WITH 子句（CTE），它在单次查询内完成层级展开，无需过程间跳转。
常见错误是试图在存储过程中写 WHILE 循环 + 临时表拼接路径，结果层级深时性能断崖式下跌，且父子关系错位难调试。
- 必须给递归 CTE 的锚点查询和递归成员之间用
UNION ALL连接，用UNION会去重并中断递归 - 递归字段顺序必须严格一致，比如锚点选了
id, parent_id, level，递归部分也得按同样顺序 SELECT - 加
MAXRECURSION 0可禁用默认 100 层限制，但务必确保有终止条件（如parent_id IS NOT NULL且不形成环）
MySQL 8.0+ 才能用 WITH RECURSIVE，低版本只能硬扛
MySQL 在 8.0 之前完全不支持递归 CTE，很多团队卡在 5.7 上，只能靠应用层多次查询或存储过程模拟递归——但这不是推荐做法。
模拟递归的典型陷阱：用循环往临时表插数据时，没控制最大深度，遇到脏数据（比如 A→B→C→A 的闭环），过程就无限跑下去，直到超时或爆内存。
- 如果必须用 MySQL 5.7，优先考虑在应用代码里做 DFS/BFS，比存储过程可控得多
- MySQL 8.0+ 写法和 SQL Server 接近，但注意语法细节：
WITH RECURSIVE是完整关键字，漏掉RECURSIVE会报错ERROR 1235 (42000): This version of MySQL doesn't yet support 'WITH RECURSIVE' - 递归查询中避免在
SELECT里调用函数（如CONCAT拼路径），某些旧版优化器会误判为不可递归而拒绝执行
PostgreSQL 的 WITH RECURSIVE 更宽松，但 cycle 检测要手动开
PostgreSQL 对递归 CTE 支持最成熟，允许在递归成员中使用聚合、窗口函数，甚至子查询，但默认不检测循环——这意味着脏数据会直接导致查询 hang 住。
很多人以为加了 UNION ALL 就安全，其实只要父子关系成环，没显式处理就会无限循环。
- 必须用
CYCLE子句，例如CYCLE id SET is_cycle USING path，否则无法提前退出 -
path字段建议用ARRAY[id]而非字符串拼接，避免 ID 含分隔符时解析错乱 - 若需按层级排序输出，用
ORDER BY array_length(path, 1)比依赖level计数更可靠
Oracle 的 CONNECT BY 是特例，别和 CTE 混用
Oracle 用 CONNECT BY 查树是传统方案，语法和语义都和标准 CTE 完全不同。强行在 PL/SQL 里嵌套 CTE + 递归过程，反而触发 ORA-32044 错误（递归 WITH 不支持在 PL/SQL 块中使用）。
最常被忽略的是 START WITH 和 CONNECT BY 的执行顺序：前者只过滤根节点，后者才决定父子匹配逻辑，把过滤条件错放到 WHERE 里会导致剪枝失效。
-
CONNECT BY PRIOR child_id = parent_id表示向上找父，顺序反了就查成镜像树 - 用
LEVEL伪列时，记得ORDER SIBLINGS BY才能保证同级有序，光靠ORDER BY LEVEL会打乱兄弟顺序 - Oracle 12c+ 虽支持 CTE，但递归 CTE 和
CONNECT BY不能混在同一查询中，否则报ORA-32034: unsupported use of WITH clause
树形查询真正的复杂点不在语法，而在数据质量。哪怕 CTE 写对了，只要存在一个 parent_id 指向不存在的 id，或者两个节点互为父子，整个查询就可能失败或返回意外结果。上线前一定用 SELECT * FROM tree WHERE parent_id NOT IN (SELECT id FROM tree) OR parent_id = id 扫一遍脏数据。
