窗口函数能替代部分自连接，因其单次扫描、分组排序计算，避免笛卡尔积；适用场景需满足“单表、分组、行间计算”三要素，如row_number()取top n、lag()/lead()获取相邻行、count(*) over统计、sum() over算滚动和；但漏写order by、精度不足、range误用或无索引时反致性能下降。
窗口函数能绕过关联表的连接动作，因为它不生成中间结果集，也不做行与行之间的匹配——它只在原始数据上分组、排序、计算，一次扫描就完成原本需要多次 JOIN 或子查询的任务。
窗口函数怎么避开 JOIN 的执行逻辑
JOIN 的本质是把两表按条件配对，产生笛卡尔积再筛选；窗口函数则完全跳过这一步。比如查“每个部门工资最高的员工”，传统写法要 employees a JOIN employees b 自连接比对，或用子查询反复扫描表；而 ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) 只扫一遍表，内存里切分部门、各自排序标号，没有跨行匹配动作。
- 执行计划里看不到
Nested Loop或Hash Join，取而代之的是WindowAgg+Sort - 如果已有
(department_id, salary)复合索引，排序甚至可能被跳过 - JOIN 是“横向扩展”（行数爆炸），窗口函数是“纵向计算”（保持原行数）
哪些 JOIN 场景能被窗口函数直接替代
不是所有 JOIN 都能换，核心看是否满足「单表、分组、行间计算」三个前提：
-
ROW_NUMBER()替代找每组 Top N 记录（如最新订单、最高工资） -
LAG()/LEAD()替代关联上下行（如登录间隔、环比变化），不再依赖 ID 连续 -
COUNT(*) OVER (PARTITION BY user_id)替代 LEFT JOIN 汇总表统计订单数 -
SUM(amount) OVER (ORDER BY sale_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)替代 7 次自连接算滚动和
为什么有时候改了反而更慢
窗口函数不是自动加速器，性能倒退往往因为没看清执行路径：
- 漏写
ORDER BY：比如ROW_NUMBER() OVER (PARTITION BY dept)在 PostgreSQL 直接报错，在 MySQL/SQL Server 可能返回随机序，后续过滤失效 - 写了
ORDER BY created_at但字段精度只有秒级，多条记录时间相同 → 窗口内顺序不确定，结果不可复现 - 用
RANGE BETWEEN INTERVAL '7 days' PRECEDING，数据库无法利用索引，每行都要重扫范围 - 原 JOIN 条件极窄（如
WHERE user_id = 123），而窗口函数被迫处理全量数据
真正关键的不是“能不能用窗口函数”，而是“有没有让数据库按你预期的方式执行”——尤其是 PARTITION BY 和 ORDER BY 的组合，以及它们背后是否有对应索引支撑。
