with recursive 仅支持无权图最短跳数路径，无法实现带权图最短路径；因其缺乏状态维护、松弛更新和优先队列能力，不能模拟 dijkstra 算法的贪心调度，强行使用易导致死循环、结果错误或性能崩溃。
WITH RECURSIVE 是目前主流 SQL 引擎中唯一能直接表达图遍历逻辑的机制，但它不能直接求出最短路径——它只能做无权图的 BFS 层级展开或带环检测的路径枚举。真正意义上的“最短路径”（即按边权累加最小）在纯 SQL 中无法用嵌套子查询或单次 WITH RECURSIVE 稳定求解，原因在于 SQL 缺乏状态维护、松弛更新和优先队列能力。
WITH RECURSIVE 只能做无权图的“最短跳数”路径
当你写：
WITH RECURSIVE path AS ( SELECT id AS start, id AS end, 0 AS hops, CAST(id AS TEXT) AS route FROM nodes WHERE id = 'A' UNION ALL SELECT p.start, e.to, p.hops + 1, p.route || '->' || e.to FROM path p JOIN edges e ON p.end = e.from WHERE p.hops
- 这里
hops是跳数（边数），不是路径权重和； WHERE p.hops 是硬性保护，防止负权环或强连通图导致无限递归；- 即使你把边权塞进
hops字段，也无法保证“第一次到达某节点时就是最短”，因为递归不按权重顺序展开，SQL 不支持 Dijkstra 那种“每次取当前最小距离节点”的贪心调度。
嵌套子查询对最短路径毫无帮助
试图用多层 (SELECT ... FROM (SELECT ...)) 模拟迭代：
- 无法跨层级传递中间最优距离（SQL 子查询是独立作用域）；
- 每层只能基于上一层的静态结果，不能做“若新路径更短则覆盖”的状态更新；
- 复杂度爆炸：n 层嵌套 ≈ 暴力枚举所有长度 ≤ n 的路径，
O(|E|^n)，实际不可行。
常见错误现象：
- 查询跑满内存或超时；
- 返回的“最短”其实是任意一条可达路径，权重未必最小；
- 同一终点出现多次，但无法
GROUP BY end HAVING MIN(total_weight)同时保留完整路径字符串（聚合与非聚合字段冲突）。
真实可行的折中方案
如果你必须用 SQL 解决带权图最短路径问题，且数据量不大（节点
- 使用
WITH RECURSIVE枚举所有从源点出发、总权值 ORDER BY SUM(weight) LIMIT 1 取最小； - 示例关键结构：
WITH RECURSIVE search AS ( SELECT from_id, to_id, weight AS total_weight, ARRAY[from_id, to_id] AS path FROM edges WHERE from_id = 'A' UNION ALL SELECT s.from_id, e.to_id, s.total_weight + e.weight, s.path || e.to_id FROM search s JOIN edges e ON s.to_id = e.from_id WHERE array_length(s.path, 1)
- 性能/兼容性影响：
- PostgreSQL 支持最好；MySQL 8.0+ 和 SQL Server 也行，但 SQLite 对递归深度默认限制严（
PRAGMA recursive_triggers=ON不够，还需调max_recursive_depth）； - 边权为负时，该方法失效（可能漏掉更短路径，或因无上限陷入循环）；
- 一旦图含负权环，结果不可信，且查询可能不终止。
- PostgreSQL 支持最好；MySQL 8.0+ 和 SQL Server 也行，但 SQLite 对递归深度默认限制严（
Dijkstra 或 A* 的核心是“动态维护未访问节点中当前已知最小距离”，这需要可变状态和优先弹出——SQL 的声明式模型天然排斥这种过程式逻辑。真要落地，得把图导出后用 Python/Go 跑算法，再把结果回写数据库。强行在 SQL 里硬刚最短路径，最后卡在调试递归终止条件和权重剪枝阈值上，比换语言多花三倍时间。
