标准SQL不支持递归JOIN，必须用WITH RECURSIVE实现任意长度社交路径查询；它由锚点和递归部分组成，需严格匹配列数类型、设置终止条件与防环机制，并依赖索引优化性能。
标准SQL不支持递归JOIN，必须用WITH RECURSIVE
直接写 JOIN 多次关联好友表无法查出任意长度的社交路径——SQL标准里没有“递归JOIN”语法。想查A到B的最短路径，得靠 WITH RECURSIVE 构建层次遍历。主流数据库（PostgreSQL、SQL Server、SQLite 3.8.3+、MySQL 8.0+）支持它，但Oracle要用 CONNECT BY，语法完全不同。
递归CTE必须设终止条件，否则无限循环
常见错误是漏写递归终止条件或路径去重逻辑，导致查询卡死或返回重复路径。比如没限制最大跳数、没用 NOT EXISTS 或 ARRAY/字符串拼接防环，就会在有环图（如A→B→C→A）中陷入死循环。
- 必须设
depth <= N（例如depth <= 6），社交网络一般6度以内可达 - 必须记录已访问节点，PostgreSQL可用
ARRAY[person_id]+&&判断是否重复；MySQL可用字符串拼接加FIND_IN_SET() - 起始锚点（anchor）和递归部分（recursive term）的列数、类型要严格一致
查最短路径不能只靠ORDER BY LIMIT 1
ORDER BY depth LIMIT 1 只保证返回一条最浅路径，但若同一深度有多条等长路径，它随机返回其一，且无法知道是否存在更优解——除非你提前设好 depth 上限并确保覆盖最短距离。
- 真正找“最短”，需先用递归CTE生成所有≤N跳的路径，再用窗口函数
ROW_NUMBER() OVER (PARTITION BY target ORDER BY depth)标记每终点的最短路径 - 若只要长度不要路径，可改用
MIN(depth)聚合，性能更好 - 注意：CTE本身不索引，
person_id和friend_id字段务必建索引，否则递归层一多就慢
示例：PostgreSQL中查A到B的最短路径（含节点序列）
WITH RECURSIVE path AS (
SELECT id AS start_id, id AS current_id, ARRAY[id] AS path, 0 AS depth
FROM person WHERE name = 'Alice'
UNION ALL
SELECT p.start_id, f.friend_id, p.path || f.friend_id, p.depth + 1
FROM path p
JOIN friend f ON p.current_id = f.person_id
WHERE f.friend_id != ALL(p.path) -- 防环
AND p.depth < 6
)
SELECT p.path, p.depth
FROM path p
JOIN person pr ON p.current_id = pr.id
WHERE pr.name = 'Bob'
ORDER BY p.depth
LIMIT 1;这个查询返回的是节点ID数组和跳数。实际应用中，path 字段需再 JOIN person 拿姓名，且深度限制值要根据业务预估——设太小会漏解，太大拖慢响应。
图结构越稠密，递归分支越多，性能下降越快。真要高频查最短路径，别硬扛SQL，该上Neo4j或用Dijkstra预计算。
