SQL窗口函数与递归查询的区别_如何根据场景选择

窗口函数适合每行加计算结果，递归查询适合顺着关系向下挖掘；前者横向增强不增行数，后者纵向展开可能指数级增行。窗口函数适合"每行加个计算结果"，递归查询适合"顺着关系往下挖"窗口函数本质是 SELECT 阶段的横向增强------不改变行数，只给每行附加一个基于分组/排序的计算值；递归查询（如 WITH RECURSIVE）则是纵向展开------从种子数据出发，反复自连接生成新行，行数可能指数级增长。常见错误现象：用 ROW_NUMBER() 去尝试查组织架构的全路径，结果只能拿到直属上级，下级一层都出不来；反过来，用递归去算每个订单的累计金额，会生成大量冗余中间行，性能崩得很快。使用场景：ROW_NUMBER() / LAG() / SUM() OVER () 用于报表排名、同比环比、滚动统计；WITH RECURSIVE 用于树形结构（部门/菜单/评论回复链）、路径查找（地铁换乘）、分层展开（BOM 物料清单）参数差异：窗口函数依赖 PARTITION BY 和 ORDER BY 定义计算范围；递归查询必须明确 seed（非递归部分）和 recursive term（如何连接上一轮结果），且需有终止条件（比如 level < 10 或无新行产生）性能影响：窗口函数一般单次扫描即可完成，只要排序字段有索引，开销可控；递归查询每轮都可能触发全表或大范围连接，没写好 WHERE 过滤或深度限制，容易卡死或爆内存MySQL 8.0+ 和 PostgreSQL 的递归语法细节不同PostgreSQL 允许在递归成员中直接引用外部表，MySQL 则严格要求递归部分只能引用 CTE 自身别名，且不支持 ORDER BY 或 LIMIT 在递归分支里出现。常见错误现象：ERROR 3638 (HY000): Recursive query aborted after 1001 iterations ------ MySQL 默认递归深度上限是 1000，超了就停，不是死循环，是被安全机制掐了。MySQL 必须显式设置 cte_max_recursion_depth（会话级变量），比如 SET SESSION cte_max_recursion_depth = 2000;PostgreSQL 没硬上限，但需靠 WHERE level <= N 主动控制，否则可能无限递归两者都不支持在递归部分用聚合函数（如 COUNT()），因为每轮结果集未固定；若真要统计层级节点数，得在外层再套一层 GROUP BY窗口函数不能替代 JOIN，但能避开多数自连接想查"每个员工工资比部门平均高多少"，用 AVG(salary) OVER (PARTITION BY dept_id) 一行搞定；如果强行用子查询或自连接，不仅 SQL 膨胀，还容易因 GROUP BY 维度不对导致丢失明细行。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。