窗口函数不能替代非等值连接，但可高效替代其衍生的累计求和、组内排名、滚动聚合等有序序列计算；需严格满足PARTITION BY、ORDER BY与窗口帧三要素，而区间匹配类需求（如订单归属活动）仍须非等值连接。
窗口函数不能替代非等值连接，但绝大多数被误写成非等值自连接的聚合需求，用窗口函数更稳、更快、更少出错。
哪些“非等值连接”其实该用窗口函数？
当你看到类似这样的 SQL 时，说明你正在用低效方式做有序聚合：
SELECT a.id, a.dt, SUM(b.val) FROM t a JOIN t b ON a.id = b.id AND a.dt >= b.dt GROUP BY a.id, a.dt
这本质是“按 id 分组、按 dt 排序后的累计求和”，完全可用 SUM() OVER() 替代。典型场景包括：
- 每个用户截至某天的累计订单金额
- 滚动 7 天销售额（需
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW） - 成绩/价格/评分的组内排名（
RANK()或DENSE_RANK()） - 单行值占分组总和的百分比（
val / SUM(val) OVER (PARTITION BY group_id)）
为什么窗口函数比非等值自连接快得多？
非等值自连接隐含笛卡尔积倾向，执行计划极易退化为嵌套循环；窗口函数底层走排序 + 一次扫描，复杂度稳定在 O(n log n)。
常见错误现象：
- EXPLAIN 显示
Type: ALL且Rows列爆炸式增长 - 10 万行数据查询开始明显卡顿
- 执行计划里反复出现
DEPENDENT SUBQUERY或Correlated Subplan
实测对比：1000 万行查最新订单，ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_time DESC) 耗时 3.8 秒，等效自连接达 12.5 秒。
容易踩的坑：ORDER BY 和窗口帧必须显式写全
缺 ORDER BY 的 SUM() OVER (PARTITION BY x) 不是累计值，而是每行都显示该分组总和；只写 ORDER BY 不写窗口帧，MySQL 默认用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但时间字段有重复时可能结果不可复现。
关键点：
-
ROWS BETWEEN比RANGE BETWEEN更高效稳定，尤其当排序字段有大量重复值时 - 时间字段重复（如多笔订单同秒创建），必须补二级排序字段：
ORDER BY create_time, order_id -
LAG()/LEAD()强制要求ORDER BY，否则报错ERROR 3589
什么时候非等值连接真没法绕开？
窗口函数不解决“一对多区间匹配”，这类问题仍必须用非等值连接：
order_time BETWEEN start_time AND end_timeip_address BETWEEN start_ip AND end_ipscore >= level_min AND score
它们的本质是“查找满足范围条件的关联记录”，窗口函数没有 JOIN 能力，也无法表达跨表区间逻辑。这时候得靠 BETWEEN + 复合索引（如 (start_ts, end_ts)）硬扛。
