self join 本身不会死循环，因为它只执行一次关联；死循环仅发生在递归cte中且数据存在环、未加深度限制与路径防环时。
SELF JOIN 本身不会死循环，死循环只发生在递归查询（WITH RECURSIVE）中且数据存在环、又没加防环逻辑时；普通自连接最多查出冗余结果或性能差，但不会卡住或报错。
为什么普通 SELF JOIN 不会死循环
自连接只是把一张表当两张用，执行一次就结束——它没有“反复展开”的机制。比如查员工和直属上级：
SELECT e.name, m.name AS manager FROM employees e LEFT JOIN employees m ON e.manager_id = m.id;
这条语句不管数据有没有 A→B→A 的闭环，都只做一次关联、输出固定行数。所谓“死循环”是误把递归 CTE 的问题套到了 SELF JOIN 上。
- 常见混淆点：看到结果里出现重复路径（如 Alice 出现在多行），误以为是“循环”，其实是数据天然的多对一关系或缺失 WHERE 过滤
- 真正会死循环的是
WITH RECURSIVE查询，比如组织树展开、评论链追溯，它依赖 UNION ALL 不断迭代 - MySQL 在遇到递归超深时直接报
ERROR 3636（Recursive query exceeded max recursion depth），而不是卡死——这是保护机制，不是 bug
递归 CTE 中怎么防死循环
一旦用了 WITH RECURSIVE，就必须同时做两件事：限制深度 + 检测路径环。光做一项等于没防。
- MySQL 必须设
cte_max_recursion_depth：会话级执行SET SESSION cte_max_recursion_depth = 200，不能设为 0 - PostgreSQL 必须维护
path数组并检查：锚点写ARRAY[id] AS path，递归部分加WHERE t.id != ALL(r.path) - SQL Server 必须把
OPTION (MAXRECURSION n)放在最终SELECT语句末尾，且不能放在视图内部——否则不生效 - 别用字符串拼接模拟路径（如
CONCAT(',', path, ',')），id=1和id=11会误匹配；ARRAY或JSON类型更安全
如何提前发现数据里的环
上线前必须扫一遍，不能等递归查询崩了才处理。环可能藏得很深（A→B→C→A），单靠肉眼或三层 JOIN 查不到。
- 用自连接查显式双向环：
SELECT 1 FROM org_unit t1 JOIN org_unit t2 ON t1.id = t2.parent_id AND t2.id = t1.parent_id - 对 parent_id 字段建索引，否则大表扫描极慢；同时检查是否允许
parent_id = id（自指），业务上是否合法 - 应用层写入时校验：比如部门树强制
level ，在 INSERT/UPDATE 触发器或服务代码里拦截非法父子关系 - MySQL 不支持
ARRAY，但可以用CONCAT(',', path, ',')+LIKE做简易检测，仅限小数据量验证，不可用于生产递归逻辑
最易被忽略的一点：很多人以为设了 MAXRECURSION 就万事大吉，其实如果数据里有自环（id=5 → parent_id=5），第一层就死循环，设 1000 层也没用。防环必须从数据源头和查询逻辑两端同时卡住。
