递归CTE中JOIN必须用INNER JOIN，因递归目标是找有效子节点，LEFT JOIN会引入NULL行破坏level计数和路径拼接；外层JOIN需基于递归输出的id且须在CTE内限制level以防笛卡尔积。
递归CTE本身不是JOIN，但必须配合JOIN才能向下展开层级；直接在递归部分写WHERE parent_id = tree.id是错的，必须用JOIN显式关联。
递归CTE里JOIN必须写成INNER JOIN还是LEFT JOIN？
用INNER JOIN。递归部分的目标是找子节点，逻辑上只保留有父级匹配的记录——如果某行parent_id找不到对应tree.id，它就不该出现在下一层。
-
LEFT JOIN会导致大量NULL行混入递归结果，破坏level计数和路径拼接 - 锚点查出根节点（如
WHERE manager_id IS NULL），递归部分靠JOIN收敛：只有e.manager_id = tree.id才生成新行 - 若业务要求保留“断层”节点（比如某个子部门manager_id指向不存在的上级），那是数据质量问题，不该靠JOIN类型掩盖
递归CTE和外层JOIN怎么避免笛卡尔积？
外层JOIN（比如查员工信息）必须基于递归CTE输出的id字段，且不能漏掉递归内部的深度限制。
- 错误写法：
SELECT * FROM tree JOIN employees e ON e.dept_id = tree.id—— 若tree没限制level，可能因环或深树导致膨胀 - 正确做法：递归CTE定义里加
WHERE tree.level ，再在外层<code>JOIN；SQL Server还要补OPTION (MAXRECURSION 5)兜底 - 别把限制条件挪到外层
WHERE，否则数据库先算完全部递归结果再过滤，内存和时间都浪费
路径字段拼接时JOIN顺序写反了会怎样？
会查出空结果或错层——递归部分的JOIN方向必须是“从上往下”，即子表JOIN递归CTE（父层）。
- 正确：
FROM employees e JOIN tree t ON e.manager_id = t.id→ 每个员工找其直属上级所在层 - 错误：
FROM employees e JOIN tree t ON t.manager_id = e.id→ 每个员工被当作上级去查下属，语义颠倒 - PostgreSQL报错
recursive reference must be in rightmost term of UNION，SQL Server提示does not contain a recursive reference，本质都是JOIN写反或递归引用位置不对
查某节点所有祖先时，JOIN方向和锚点怎么设？
向上递归时锚点是目标节点，JOIN方向反过来：递归部分让原始表JOINCTE，条件是原始表.id = CTE.manager_id。
- 锚点：
SELECT id, name, manager_id FROM employees WHERE id = 123 - 递归：
SELECT e.id, e.name, e.manager_id FROM employees e JOIN upline u ON e.id = u.manager_id→ 用当前层的manager_id去查上级本人 - 注意终止：加
WHERE e.manager_id IS NOT NULL防无限循环，比单纯靠level更可靠
真正容易被忽略的不是语法，而是JOIN方向和收敛逻辑——写错一次，结果要么为空，要么爆炸，且很难一眼看出问题在哪。
