窗口函数不能直接替代非等值连接，但可高效替代其衍生的累计求和、组内排名、滚动聚合等有序序列计算；需严格满足partition by、order by与窗口帧三要素，而区间匹配类需求（如订单归属活动）仍须非等值连接。
窗口函数不能直接替代非等值连接，但绝大多数原本靠非等值自连接实现的聚合需求（比如累计求和、组内排名、区间归属），用窗口函数更简洁、更高效——只要你的数据库支持 OVER() 语法（MySQL 8.0+、PostgreSQL、SQL Server、Oracle 等主流版本都支持）。
什么时候该放弃非等值自连接，改用窗口函数？
当你在写类似这样的 SQL 时，就是信号：
SELECT a.id, a.month, SUM(b.GMV) FROM sales a JOIN sales b ON a.id = b.id AND a.month >= b.month GROUP BY a.id, a.month
这本质是在做“按 id 分组、按 month 排序后的累计求和”，完全可以用 SUM() OVER() 替代。常见触发场景包括：
- 计算每个用户截至某天的累计订单金额
- 按时间排序后统计滚动 7 天销售额
- 对成绩/价格/评分做组内排名（
RANK()/DENSE_RANK()） - 求个人值占分组总和的百分比
非等值自连接的问题是：它隐含笛卡尔积倾向，数据量一过万行，执行计划极易退化为嵌套循环，而窗口函数底层通常走排序 + 一次扫描，复杂度稳定在 O(n log n)。
SUM() OVER(PARTITION BY ... ORDER BY ...) 的关键参数组合
累计类聚合的核心就是这三个部分必须同时出现，缺一不可：
-
PARTITION BY：定义“在哪个维度内累计”，比如PARTITION BY user_id表示每人单独累计 -
ORDER BY：定义累计顺序，比如ORDER BY order_date决定“从哪天开始加” - 窗口帧（frame）：默认是
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，也就是从分区开头加到当前行；如果要算滚动窗口（如最近 3 条记录），就得显式写ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
错误写法示例：SUM(GMV) OVER(PARTITION BY user_id) —— 缺少 ORDER BY，结果等价于每行都显示该用户的总 GMV，不是累计值。
非等值连接无法被窗口函数替代的典型场景
窗口函数处理的是“有序序列上的局部聚合”，它不解决“一对多区间匹配”问题。以下情况仍需非等值连接：
- 订单时间匹配促销活动周期：
order_time BETWEEN start_time AND end_time - IP 地址落入某个 CIDR 段或地理围栏范围
- 用户积分落在某个等级区间（如 1000–1999 → 银卡）
这类查询的本质是“查找满足范围条件的关联记录”，窗口函数没有 JOIN 能力，也无法表达跨表的区间逻辑。强行用子查询 + WHERE EXISTS 或 LATERAL（PostgreSQL）可能更慢，且可读性差。
性能与兼容性要注意的硬伤
即使你决定用窗口函数，也得留意这些现实约束：
- MySQL 5.7 及更早版本不支持窗口函数，升级前别硬套
OVER() - Oracle 对
ORDER BY字段要求严格：如果ORDER BY create_time有重复值，累计结果可能不稳定（相同时间戳的行顺序不确定），建议补一个唯一字段如ORDER BY create_time, id -
ROW_NUMBER()和RANK()在遇到相同值时行为不同：前者强制给不同序号，后者并列同号跳号，选错会导致业务逻辑出错 - 大数据量下，
OVER(PARTITION BY x ORDER BY y)会触发全局排序，若y列无索引，SORT 操作本身就成了瓶颈
真正容易被忽略的，不是语法怎么写，而是没想清楚“这个需求到底是不是区间匹配”。看到“累计”“排名”“占比”就条件反射用窗口函数，看到“落在XX范围内”就本能写非等值 JOIN —— 判断错了，后面所有优化都是徒劳。
