窗口函数可替代部分自连接，但仅限“同表分组内行间计算”场景；需严格匹配partition by与排序、处理null及并列、避免where直接引用、关注执行计划与边界情况。
能替代，但必须分清场景——窗口函数不是自连接的“万能替换键”，而是针对“组内行间计算”这类需求的精准解法。
哪些自连接聚合能被窗口函数直接替代
核心判断标准：是否在做「同一张表内、按某字段分组、对每行计算一个基于组内其他行的值」？符合就大概率能换。
- 查每个用户最新订单（用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC)） - 统计每个部门薪资高于本部门平均值的员工数（用
COUNT() OVER (PARTITION BY dept_id)配合条件聚合） - 计算相邻两条登录记录的时间差（用
LAG(login_date) OVER (PARTITION BY user_id ORDER BY login_date)） - 滚动7天销售额（用
SUM(amount) OVER (ORDER BY order_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)）
不能换的典型：需要跨不同分组做关联（比如“找A部门工资最高的员工和B部门入职最早的员工配对”），或涉及多跳关系（如经理的经理），这些仍得靠JOIN或递归CTE。
ORDER BY 在窗口函数里不是可选的
写 ROW_NUMBER() OVER (PARTITION BY dept_id) 不加 ORDER BY，SQL Server 会按物理存储顺序排，结果不可复现——尤其在数据有增删后，同一条语句可能返回不同员工。
- 必须显式写出排序依据，例如
ORDER BY salary DESC, id：salary 相同时用id保序 - 如果业务字段允许 NULL（比如
hire_date可为空），要主动指定NULLS LAST（SQL Server 不支持该语法，需用IS NULL表达式兜底） - 错误示例：
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)—— 当多人同薪时，每次执行可能返回不同 top 1
性能反而更差的常见原因
窗口函数不是自动加速器。它快，是因为避免了笛卡尔积；但它慢，是因为你让它干了不该干的活。
- 没加
PARTITION BY却写ORDER BY created_at：全表排序，O(n log n)，比带索引的自连接还重 - 用
RANK()替代ROW_NUMBER()却只取rn = 1：并列时多返回几行，下游逻辑可能崩（比如插入唯一约束表） - 在 WHERE 中引用窗口函数别名（如
WHERE rn = 1）却不包一层子查询或 CTE：SQL Server 报错，必须先生成中间结果集 - 原自连接本身已加了高效索引（如
(user_id, created_at)覆盖索引），而窗口函数触发了大排序且无内存缓冲，IO 成瓶颈
真正落地时容易被忽略的细节
最常翻车的地方不在语法，而在数据语义的隐含假设。
-
PARTITION BY字段必须和原自连接的ON条件完全一致，否则分组错位（比如原连接是ON o1.user_id = o2.user_id AND o1.status = o2.status，那窗口必须PARTITION BY user_id, status） - 用
LAG()计算差值时，第一行默认是NULL，若参与运算（如amount - LAG(amount)），整列变NULL——要加第三个参数设默认值，如LAG(amount, 1, 0) - SQL Server 2012+ 支持全部主流窗口函数，但旧版本不支持
ROWS BETWEEN的完整语法，UNBOUNDED PRECEDING是安全的，2 PRECEDING可能报错
换之前先看执行计划里的 Sort 和 Window Aggregate 步骤耗时占比；换之后别只验结果对不对，要盯住逻辑是否覆盖了所有边界情况——比如并列、NULL、空分组。
