窗口函数避开笛卡尔积，因它不关联行而是单次扫描分组排序；仅适用于单表、分组、行间计算场景，如ROW_NUMBER()取最新记录、LAG()算差值、COUNT() OVER统计组内条件，但需严格写PARTITION BY和ORDER BY。
窗口函数能绕过自连接最根本的瓶颈：它不生成中间笛卡尔积，而是直接在原始行集上做分组内计算。
窗口函数怎么避开笛卡尔积
自连接查“每个用户最新订单”，本质是让每条订单和同用户所有其他订单逐条比时间——数据量一上来，orders o1 JOIN orders o2 就爆炸。窗口函数只扫一遍表，在内存里按 PARTITION BY user_id 切成若干子集，再对每个子集独立排序标号，没有跨组匹配动作。
- 自连接执行计划里常见
Nested Loop或Hash Join，成本随行数平方增长 - 窗口函数执行计划通常是
WindowAgg+Sort，成本为O(n log n)，且只排一次序 - 如果已有
(user_id, created_at)复合索引，ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)可能连排序都省了（索引已有序）
哪些自连接逻辑能被窗口函数直替
不是所有自连接都能换，核心看是否满足「单表、分组、行间计算」三要素：
-
ROW_NUMBER()替代找最新/最早记录（如NOT EXISTS子查询或LEFT JOIN ... IS NULL） -
LAG()/LEAD()替代关联上/下一行（如计算环比、登录间隔），不再依赖 ID 连续 -
COUNT() OVER (PARTITION BY ...)替代JOIN汇总表统计（如每个客户订单数），避免多次扫描 -
SUM() OVER (ORDER BY ... ROWS BETWEEN ...)替代自连接算滚动窗口（如 7 天累计），不用JOIN七次
为什么有时候换了反而更慢
窗口函数不是银弹。性能倒退往往因为没看清执行路径：
- 写了
ORDER BY created_at却漏掉PARTITION BY→ 全表排序，比带索引的自连接还重 - 原自连接条件本身极窄（如
WHERE user_id = 123后再 JOIN），而窗口函数被迫处理全量数据 - 用
RANGE BETWEEN INTERVAL '7 days' PRECEDING，数据库无法利用索引，每行都要重新扫描匹配范围 - SQL Server 或 MySQL 在内存不足时把窗口排序刷到磁盘，IO 成瓶颈；而自连接若走索引嵌套循环，可能更快
ORDER BY 不写就是埋雷
几乎所有翻车都源于这个细节：窗口函数里 ORDER BY 不是可选语法糖，而是语义必需项。
-
ROW_NUMBER() OVER (PARTITION BY dept)在 PostgreSQL 报错，在 SQL Server 和 MySQL 可能返回随机顺序结果 - 时间字段精度不够（如只有秒级）时，必须补唯一字段：
ORDER BY created_at DESC, id DESC -
LAG(amount) OVER (PARTITION BY user_id ORDER BY created_at)遇到同秒多笔订单，前一行不确定——下游差值计算就不可复现 - NULL 值要显式处理：
ORDER BY hire_date DESC NULLS LAST（PostgreSQL/Oracle），SQL Server 得写ORDER BY CASE WHEN hire_date IS NULL THEN 1 ELSE 0 END, hire_date DESC
真正难的从来不是写出窗口函数，而是判断该不该换、在哪加 PARTITION BY、怎么写 ORDER BY 才让结果既快又稳。数据分布和索引现状，永远比函数名更重要。
