窗口函数能直接替代大部分“跟自己比”的自连接场景，如查最新订单、组内Top3、相邻行差值等，通过ROW_NUMBER()、RANK()、LAG()等实现逻辑简化与正确性提升。
窗口函数能直接替代哪些自连接场景
大部分需要“跟自己比”的聚合需求，比如查每个用户最新订单、统计每组内排名前3的记录、计算相邻行差值——这些用自连接写起来啰嗦又慢，ROW_NUMBER()、RANK()、LAG()、LEAD() 几个函数就能压平逻辑。
关键不是“能不能换”，而是“换完会不会错”：窗口函数按 PARTITION BY 分组后独立排序，不产生笛卡尔积，天然规避了自连接里漏条件、重复匹配、NULL 误判等经典翻车点。
- 查最新一条记录？用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)+ 外层WHERE rn = 1 - 算滚动7天销售额？
SUM(amount) OVER (ORDER BY order_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) - 对比上一笔订单金额？
LAG(amount) OVER (PARTITION BY user_id ORDER BY created_at)
ORDER BY 在窗口函数里不是可选的
很多同学写 ROW_NUMBER() OVER (PARTITION BY x) 不加 ORDER BY，结果发现序号乱跳、每次执行结果不一致——这是数据库明确未定义行为，PostgreSQL 报错，MySQL 8.0+ 和 SQL Server 会默认按物理存储顺序排，但这个顺序不可靠。
真正要的是确定性排序：时间戳、ID、业务主键都行，但必须显式写出。如果真没自然排序字段，至少加个 ORDER BY id（哪怕 id 是自增），别空着。
- 错误写法：
ROW_NUMBER() OVER (PARTITION BY dept) - 正确写法：
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY hire_date, id) - 注意：多个字段排序时，
NULLS FIRST/LAST要主动指定，否则不同数据库默认不同
自连接改窗口函数后性能为什么可能更差
不是所有自连接都适合换。如果原查询只关联少量行（比如只找每个用户的上一条记录，且有索引），而窗口函数被迫对全表排序（OVER (ORDER BY ...) 没带 PARTITION BY），那开销反而更大。
核心看数据分布和过滤时机：窗口函数在 WHERE 之后执行，无法提前剪枝；自连接却可能利用索引快速定位关联行。
- 适合换：分组内聚合、全局排序取 Top N、固定窗口范围计算
- 慎换：只关联当前行附近几条、关联条件含复杂表达式或函数、结果集本身很小（
- 验证方法：对比执行计划里的
Sort和Nested Loop成本，别光看代码行数
MySQL 5.7 和 PostgreSQL 的兼容性坑
MySQL 5.7 不支持窗口函数，强行用会报错 FUNCTION xxx does not exist；升级到 8.0+ 才行。PostgreSQL 从 9.4 开始支持，但早期版本不支持 EXCLUDE CURRENT ROW 这类高级子句。
另一个隐形坑是 NULL 处理：SQL Server 默认把 NULL 当最小值，PostgreSQL 默认当最大值，ORDER BY col ASC 在不同库结果可能颠倒。
- 跨库迁移时，务必检查
NULLS FIRST或NULLS LAST显式声明 - MySQL 5.7 用户想用类似功能，只能退化为变量模拟（
@row := @row + 1），但并发下不安全，别在线上用 - PostgreSQL 中
RANK()和DENSE_RANK()对并列处理不同，别只测一个例子就上线
窗口函数不是银弹，它把逻辑变清晰了，但排序成本、NULL 行为、数据库版本限制这些细节，一不留神就让结果错得悄无声息。
