不能。MySQL的WITH RECURSIVE仅支持递归展开，无剪枝、优先队列或距离更新机制，只能穷举可达性或固定层级路径；查某节点到根的完整路径是最稳妥场景，需明确方向、无环、单路径，并控制深度与自引用。
WITH RECURSIVE 能直接算最短路径吗？
不能。MySQL 的 WITH RECURSIVE 仅支持递归展开，不提供图遍历的剪枝、优先队列或距离更新机制，本质上是深度/广度“穷举”，无法天然保证“最短”。它适合查**可达性**或**固定层级路径**（比如组织架构向上查 3 级领导），但对任意图的最短路径，会因重复访问、无序扩展导致结果不可靠甚至死循环。
怎么用 WITH RECURSIVE 查“某节点到根的完整路径”？
这是它最稳妥的使用场景：有明确方向（如 parent_id → id）、无环、单路径。关键点是控制递归深度和避免自引用：
- 起始查询（anchor）必须只选目标叶子节点，
SELECT id, name, parent_id, 0 AS depth - 递归部分用
JOIN关联自身，且ON t.parent_id = r.id（注意方向） - 必须加
WHERE r.depth 类似保护，防止意外环导致无限递归 - 最终
ORDER BY depth DESC可得从根到叶子的顺序
WITH RECURSIVE path AS ( SELECT id, name, parent_id, 0 AS depth FROM org WHERE id = 123 UNION ALL SELECT t.id, t.name, t.parent_id, p.depth + 1 FROM org t INNER JOIN path p ON t.id = p.parent_id WHERE p.depth < 10 ) SELECT * FROM path ORDER BY depth DESC;
为什么加了 LIMIT 还可能查出多条路径？
因为递归过程不排重——如果图中存在多个父路径（如 DAG 或数据脏），同一节点可能被多次推入结果集。MySQL 不支持 RECURSIVE 中的 DISTINCT 或 GROUP BY，所以必须从业务层约束结构（比如强制树形、加唯一索引 (id, parent_id)），或在外部用 GROUP BY id 去重（但会丢失深度信息）。
- 常见错误：把
parent_id写成id = p.parent_id（方向反了，查成子节点） - 更隐蔽的问题：
parent_id允许为 NULL，但 anchor 没过滤，导致第一行就 NULL 匹配失败 - 性能陷阱：没给
parent_id加索引，递归每层都全表扫描
真要算最短路径，该换什么方案？
别硬扛。MySQL 不是图数据库。简单场景可导出后用 Python（networkx）或 Node.js（graphology）跑 Dijkstra；复杂或高频需求，直接上 Neo4j、Nebula 或 PostgreSQL 的 pg_graphql + cypher。如果必须在 MySQL 里凑合，只能用存储过程模拟 BFS：建临时表存“当前层节点+距离”，循环 INSERT ... SELECT 扩展下一层，每次检查是否命中目标——但这已完全脱离 WITH RECURSIVE 的简洁性，且并发和维护成本陡增。
真正容易被忽略的是：很多人以为加了 RECURSIVE 就能自动优化图查询，其实它连环检测都要靠你手动加 depth 截断和 path_array 字符串记录（MySQL 8.0.22+ 支持 JSON_CONTAINS 判断是否已访问），而这些手工逻辑一多，就比写个应用层循环还难 debug。
