必须设终止条件，否则存在环时会无限运行；postgresql用array+not any防环，mysql用find_in_set模拟，sql server依赖option(maxrecursion)。
用 WITH RECURSIVE 检测循环前必须设终止条件
PostgreSQL、SQL Server（T-SQL）、MySQL 8.0+ 支持递归 CTE，但默认不限制递归深度——一旦存在环，查询会无限运行直至超时或被 kill。必须显式限制层级或路径长度。
常见做法是记录已遍历的 id 路径（如用 ARRAY 或字符串拼接），并在每次递归时检查当前 child_id 是否已在路径中。例如 PostgreSQL 中：
WITH RECURSIVE tree_path AS ( SELECT id, parent_id, ARRAY[id] AS path FROM org_unit WHERE parent_id IS NULL UNION ALL SELECT o.id, o.parent_id, tp.path || o.id FROM org_unit o JOIN tree_path tp ON o.parent_id = tp.id WHERE NOT o.id = ANY(tp.path) -- 关键：防环 )
MySQL 不支持 ARRAY，可用 CONCAT(',', path, ',') + LIKE 模拟，但性能较差；更稳妥的是加 LEVEL 计数并设 MAXRECURSION 100（SQL Server）或 cte_max_recursion_depth=200（MySQL 配置级兜底）。
SELF JOIN 只能查两层关系，无法发现深层循环
单纯用 JOIN org_unit a ON a.id = b.parent_id 这类自连接，最多追溯固定层数（如 3 层需写 3 次 JOIN）。它本质是静态展开，对「A→B→C→A」这类三跳闭环完全无感。
典型误用场景：
- 用
SELECT * FROM org_unit a JOIN org_unit b ON a.id = b.parent_id JOIN org_unit c ON b.id = c.parent_id WHERE a.id = c.parent_id—— 这只捕获「祖父=曾孙」型环，漏掉「父→子→孙→父」等任意长度环 - 把
parent_id = id当作环（即自引用），但业务中合法的自引用（如部门负责人兼任本部门主管）不等于逻辑错误，需结合上下文判断
自连接适合快速筛查明显异常（如 parent_id = id 或 parent_id IS NULL AND id != root_id），但不能替代递归检测。
不同数据库对循环检测的支持差异很大
Oracle 用 CONNECT BY NOCYCLE 自动标记环节点（CONNECT_BY_ISCYCLE 返回 1），无需手动维护路径；SQLite 无原生递归 CTE（除非编译时启用），只能靠应用层多次查询模拟；而 SQL Server 的 OPTION (MAXRECURSION n) 是强制安全阀，不加可能直接卡死会话。
关键兼容点：
- PostgreSQL：依赖
NOT x = ANY(array)或@> operator判断路径包含 - MySQL：用
FIND_IN_SET(child_id, path_str)替代数组，但注意path_str长度上限（GROUP_CONCAT_MAX_LEN） - SQL Server：用
ISNULL(parent_id, 0) > 0避免NULL在递归中中断，且必须在 anchor 和 recursive 部分都处理parent_id为 NULL 的情况
生产环境必须加索引和提前过滤
递归查询性能极度依赖 parent_id 字段的索引。没索引时，每轮递归都要全表扫描，N 层递归 ≈ N×全表扫描。
实际部署前务必确认：
- 有
INDEX ON org_unit(parent_id)（单列即可，不用复合索引） - 先用
WHERE parent_id IS NOT NULL排除根节点，减少 anchor 集合大小 - 若只关心「是否存在环」而非完整路径，可在检测到首个环时用
LIMIT 1（PostgreSQL/MySQL）或TOP 1（SQL Server）提前退出 - 避免在递归 CTE 中 JOIN 其他大表——CTE 每轮都会重复执行 JOIN，复杂度爆炸
最易被忽略的一点：循环检测语句本身不该放在高频事务里执行。应该作为运维脚本定期跑，或在插入/更新 parent_id 时由触发器或应用层校验，而不是每次查组织架构都重算一遍。
