窗口函数不能用于图遍历，因其不改变行数且不控制访问顺序；图遍历必须依赖WITH RECURSIVE按拓扑序逐层展开，且递归内部禁用窗口函数。
窗口函数本身不直接处理图结构，PostgreSQL 也没有原生图数据类型或图遍历语法。所谓“图查询性能提升”，实际是用窗口函数辅助递归CTE（WITH RECURSIVE）做树/图遍历后的结果分析——比如层级统计、路径聚合、环检测辅助判断等。直接在窗口函数里写图遍历会报错或逻辑失效。
为什么不能把窗口函数当图遍历用
窗口函数运行在最终结果集上，它不改变行数，也不控制数据访问顺序；而图遍历（如评论树、组织架构、依赖关系）必须按拓扑顺序逐层展开，这只能靠WITH RECURSIVE完成。你如果在递归CTE外部套一层SUM(...) OVER (ORDER BY depth)没问题，但若试图在递归内部用ROW_NUMBER() OVER (...)来“标记访问顺序”，PostgreSQL会报错：ERROR: window functions are not allowed in recursive queries。
递归CTE + 窗口函数的正确协作方式
典型场景：查出整棵评论树后，立刻算出每层的平均回复时长、用户发评频次、路径长度分布。这时窗口函数是“后处理”角色，不是“遍历引擎”。
- 递归部分只负责生成带
depth、path、cycle标志的中间结果 - 主查询中再用
COUNT(*) OVER (PARTITION BY depth)统计每层节点数 - 用
STRING_AGG(content, ' → ' ORDER BY depth) OVER (PARTITION BY root_id)拼接路径（需PostgreSQL 16+支持并行string_agg） - 用
LAG(created_at) OVER (PARTITION BY root_id ORDER BY depth)计算父子节点时间差
性能关键：索引必须覆盖递归输出字段
递归CTE输出的depth、root_id、created_at等字段，如果要在后续窗口函数中PARTITION BY或ORDER BY，必须有对应索引支撑，否则窗口计算会触发全量排序。例如：
CREATE INDEX idx_comments_tree_lookup ON comments (parent_id, id) INCLUDE (content, created_at);
这个索引让递归JOIN c.parent_id = ct.id走索引查找；而后续窗口函数若按root_id分组，就得额外建：
CREATE INDEX idx_comment_tree_root_depth ON comment_tree (root_id, depth);
注意：comment_tree是CTE别名，真实表不存在——所以这个索引得建在物化结果表上，或改用MATERIALIZED VIEW（PostgreSQL 9.3+）缓存递归结果。
容易被忽略的环检测陷阱
图可能含环（如A→B→C→A），WITH RECURSIVE默认会报错退出。必须显式用SEARCH DEPTH FIRST和CYCLE子句捕获：
WITH RECURSIVE comment_tree AS ( SELECT id, parent_id, ARRAY[id] AS path, false AS cycle FROM comments WHERE parent_id IS NULL UNION ALL SELECT c.id, c.parent_id, ct.path || c.id, c.id = ANY(ct.path) FROM comments c JOIN comment_tree ct ON c.parent_id = ct.id WHERE NOT ct.cycle ) SELECT *, COUNT(*) OVER (PARTITION BY id) AS in_degree FROM comment_tree;
这里in_degree是窗口函数计算的入度，但它依赖id字段——如果没对id建主键或唯一索引，COUNT(*) OVER (PARTITION BY id)会因重复id导致结果错乱。图数据导入时主键冲突、软删除未清理，都可能让id失去唯一性，这点比普通业务表更敏感。
