窗口函数适合每行加计算结果，递归查询适合顺着关系向下挖掘；前者横向增强不增行数，后者纵向展开可能指数级增行。
窗口函数适合“每行加个计算结果”，递归查询适合“顺着关系往下挖”
窗口函数本质是 SELECT 阶段的横向增强——不改变行数，只给每行附加一个基于分组/排序的计算值；递归查询（如 WITH RECURSIVE）则是纵向展开——从种子数据出发，反复自连接生成新行，行数可能指数级增长。
常见错误现象：用 ROW_NUMBER() 去尝试查组织架构的全路径，结果只能拿到直属上级，下级一层都出不来；反过来，用递归去算每个订单的累计金额，会生成大量冗余中间行，性能崩得很快。
- 使用场景：
ROW_NUMBER()/LAG()/SUM() OVER ()用于报表排名、同比环比、滚动统计；WITH RECURSIVE用于树形结构（部门/菜单/评论回复链）、路径查找（地铁换乘）、分层展开（BOM 物料清单） - 参数差异：窗口函数依赖
PARTITION BY和ORDER BY定义计算范围；递归查询必须明确seed（非递归部分）和recursive term（如何连接上一轮结果），且需有终止条件（比如level 或无新行产生） - 性能影响：窗口函数一般单次扫描即可完成，只要排序字段有索引，开销可控；递归查询每轮都可能触发全表或大范围连接，没写好
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 主动控制，否则可能无限递归 - 两者都不支持在递归部分用聚合函数（如
COUNT()），因为每轮结果集未固定；若真要统计层级节点数，得在外层再套一层GROUP BY
窗口函数不能替代 JOIN，但能避开多数自连接
想查“每个员工工资比部门平均高多少”，用 AVG(salary) OVER (PARTITION BY dept_id) 一行搞定；如果强行用子查询或自连接，不仅 SQL 膨胀，还容易因 GROUP BY 维度不对导致丢失明细行。
容易踩的坑：在 WHERE 条件里直接引用窗口函数结果，比如 WHERE ROW_NUMBER() OVER (...) > 1 —— 大多数数据库（包括 PostgreSQL、MySQL）会报错 window function is not allowed in WHERE clause，因为 WHERE 执行顺序在窗口计算之前。
- 正确做法：把窗口函数包进子查询或 CTE，外层再过滤
- 另一个坑：
ORDER BY子句里用了窗口函数，但没在SELECT列表中出现——某些数据库（如旧版 Hive）会拒绝执行，建议显式写出 - 性能提示：
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW比默认的ROWS更重，尤其大数据量时，除非真需要逻辑区间语义，否则别乱改
递归查询结果默认无序，窗口函数依赖显式 ORDER BY
递归出来的行顺序不保证是“从根到叶子”的自然深度优先，PostgreSQL 默认按执行顺序返回，MySQL 也类似；而窗口函数里的 ORDER BY 是强制参与计算的，缺了它，LAG()、LEAD()、累计求和这些就失去意义。
最常被忽略的一点：递归查询中，ORDER BY 只能放在最终 SELECT 外层，不能在递归分支里写——这不是语法错误，而是根本无效。想按层级+名称排序输出，得靠外层 ORDER BY level, name。
- 窗口函数的
ORDER BY必须出现在OVER子句里，且字段需在当前作用域可见（不能是子查询别名，除非提升到外层） - 如果业务要求“显示完整路径字符串”，比如
/IT/Dev/Backend，递归里得用||（PostgreSQL）或CONCAT()（MySQL）拼接，且注意首层路径别多出斜杠 - 没有索引支撑的递归字段（如父ID列），首次执行可能极慢；窗口函数若
PARTITION BY字段没索引，ORDER BY又复杂，排序阶段也会拖垮整体
