mysql 8.0+ 用 with recursive 实现树形路径查询需锚点初始化 path 字段并逐层 concat 拼接，严格匹配 join 条件、控制字段长度、避免 null 截断，且须通过 where 隐式终止或 level 计数防死循环。
MySQL 8.0+ 怎么用 WITH RECURSIVE 做树形路径查询
MySQL 8.0 之前没法直接递归查父子路径，必须靠存储过程或应用层拼接；8.0+ 支持 WITH RECURSIVE，这才是真正能一次性拿到完整路径的方案。
关键不是写个 JOIN，而是用递归 CTE 构建路径字符串。常见错误是把递归当成普通 JOIN 写，结果只查一层就停了。
-
WITH RECURSIVE必须包含 anchor（起点）和 recursive（自引用）两部分，缺一不可 - 递归查询里不能用
GROUP BY或聚合函数（除非在外部包装一层） -
CONCAT拼路径时注意分隔符和 NULL 处理，比如CONCAT(t2.path, '/', t1.name)中如果t2.path是 NULL，整段变 NULL —— 得用COALESCE(t2.path, '') - 必须加
MAX_RECURSION_DEPTH限制（默认 1000），否则环状数据会死循环，执行前设SET SESSION cte_max_recursion_depth = 100;
WITH RECURSIVE tree_path AS (
SELECT id, parent_id, name, CAST(name AS CHAR(1000)) AS path
FROM categories WHERE parent_id IS NULL
UNION ALL
SELECT t.id, t.parent_id, t.name,
CONCAT(COALESCE(p.path, ''), '/', t.name)
FROM categories t
INNER JOIN tree_path p ON t.parent_id = p.id
)
SELECT * FROM tree_path;
PostgreSQL 的 CONNECT BY 等价写法是啥
PostgreSQL 没有 CONNECT BY，但 WITH RECURSIVE 更灵活，且原生支持 ARRAY 和 array_to_string 构建路径，比 MySQL 字符串拼接更安全。
容易踩的坑是忽略 SEARCH DEPTH FIRST 或 BREADTH FIRST 控制遍历顺序，导致排序不符合预期（比如想按树层级展示却得到随机顺序）。
- 用
ARRAY[...] || t.name累积路径数组，避免字符串截断风险 - 最后用
array_to_string(path_array, ' > ')转成可读格式 - 必须在递归分支里限制
WHERE t.parent_id IS NOT NULL，否则 anchor 部分会重复进入递归 - PostgreSQL 默认不限制递归深度，但实际运行中可能因内存溢出失败，建议显式加
WHERE depth 辅助防护
SQL Server 的 FOR XML PATH 怎么模拟路径拼接
SQL Server 2005+ 不支持标准递归 CTE 的路径聚合（早期版本），常用 FOR XML PATH('') + 自连接来“伪递归”，本质是 N 层手工 JOIN，最多撑到 5–6 层就难维护。
这不是真递归，只是把有限层级展开，所以一旦树深超过预设，结果就漏节点 —— 别被网上“一行搞定”的示例误导。
- 每多一层就得加一个
LEFT JOIN，比如 4 层路径要连 4 次同一张表 -
FOR XML PATH('')返回 XML 类型，得用.value('.', 'VARCHAR(MAX)')提取文本 - 空值会导致整个拼接结果为 NULL，每个字段都要套
ISNULL(col, '') - 性能差：N 层 JOIN 产生笛卡尔积风险，数据量稍大就慢，不如迁移到
WITH RECURSIVE（SQL Server 2022+ 已支持）
为什么不能只靠 LEFT JOIN 实现任意深度路径
LEFT JOIN 只能固定连接次数，比如连 3 次最多查 4 级节点；而真实业务中树深度不确定，用户可能突然加 10 层分类，这时 SQL 就得重写 —— 这不是扩展性问题，是模型错配。
有人试图用多次 UNION ALL 模拟递归，但每层都要手写 JOIN 条件，逻辑重复、易出错，且无法动态响应深度变化。
- 所有基于固定
JOIN数量的方案，本质上都是“展开递归”，不是递归本身 - Oracle 的
CONNECT BY、PostgreSQL/MySQL 的WITH RECURSIVE才是语言级支持，由优化器统一处理迭代逻辑 - 即使数据库支持递归，也要警惕数据中存在环（parent_id 循环指向），必须在递归 CTE 中用
NOT EXISTS (SELECT ...)或路径数组去重来防死循环
路径查询真正的复杂点不在语法，而在如何让递归安全终止、如何让路径字符串不因长度或空值崩掉、以及怎么验证结果里没混入环状脏数据 —— 这些都得在 CTE 里显式控制，而不是依赖 JOIN 的“看上去很像”。
