一般来说，窗口函数的执行效率往往高于自连接。原因并不复杂：它通常只需要做一次全表扫描、一次排序，再配合一次临时结构构建，整体时间复杂度大约是O(n log n)；反过来看，自连接往往会在主表的每一行上触发一次副表扫描，处理不当时，很容易退化成O(N)。

窗口函数性能更好，但前提是写法正确、索引匹配、场景合适。盲目替换反而可能更慢。

为什么窗口函数通常比自连接快？

核心区别在执行路径：窗口函数只扫一次表、排一次序、建一次临时结构；自连接对主表每行都触发一次副表扫描，容易变成 O(N)。 常见错误现象： EXPLAIN 显示 Type: ALL 且 Rows 列爆炸式增长 执行计划反复出现 DEPENDENT SUBQUERY 或 Nested Loop 查询耗时随数据量非线性暴涨，10 万行就开始卡顿 实操建议： 确保 PARTITION BY 和 ORDER BY 字段有复合索引，例如 (customer_id, order_time DESC) 时间字段重复时，补二级排序字段，如 ORDER BY order_time DESC, id DESC 别省略 ROWS 关键字——用 RANGE 在时间字段上会把同一天多笔订单全纳入，导致重复累加

哪些自连接能直接换？

不是所有都能换，关键看是否满足「单表、分组、行间计算」三要素： 查最新/最早记录 → 用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) 算相邻差值（环比、登录间隔）→ 用 LAG(amount) OVER (PARTITION BY user_id ORDER BY event_time) 滚动窗口统计（7天累计）→ 用 SUM(amount) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) 组内条件计数（薪资高于本部门平均的人数）→ 用 COUNT(CASE WHEN salary > A VG(salary) OVER (PARTITION BY dept_id) THEN 1 END) OVER (PARTITION BY dept_id) 注意：LAG() 和 LEAD() 必须带 ORDER BY，否则 MySQL 8.0+ 报错 ERROR 3589 (HY000): Window '' requires an ORDER BY clause

为什么换了反而更慢？

窗口函数不是银弹，性能倒退往往因为： 漏写 PARTITION BY，导致全表排序，比带索引的自连接还重 原自连接本身过滤极窄（如 WHERE user_id = 123 后再 JOIN），而窗口函数被迫处理全量数据 用了 RANGE BETWEEN INTERVAL '7 days' PRECEDING，数据库无法利用索引，每行都要重新扫描匹配范围 内存不足时，MySQL 把窗口排序刷到磁盘，IO 成瓶颈；而索引驱动的嵌套循环 JOIN 可能更快 验证方法：对比 EXPLAIN 里的 Sort 和 Nested Loop 成本，别光看代码行数

ORDER BY 是语义必需，不是可选语法糖

很多翻车都源于空着 ORDER BY： ROW_NUMBER() OVER (PARTITION BY dept) 在 PostgreSQL 直接报错，在 MySQL 8.0+ 默认按物理存储顺序排——但删过数据、批量插入、分布式主键都会让这个顺序不可靠 时间戳精度不够（如只有秒级）时，必须补唯一字段：ORDER BY created_at DESC, id DESC LAG(value, 1, 0) 第三个参数设默认值，避免 NULL 污染后续计算（比如做减法得 NULL） 真正要的是确定性排序：时间戳、ID、业务主键都行，但必须显式写出。如果真没自然排序字段，至少加个 ORDER BY id，别空着。