MySQL 8.0引入的窗口函数，为分组排序、累计统计等场景提供了更简洁的实现方式，相比传统的子查询方案，在性能上有明显优势。这种优势并非偶然，而是源于两者底层执行逻辑的本质差异。
窗口函数与子查询的基础概念
窗口函数是对一组行进行计算的函数，这组行被称为窗口，函数不会将多行合并成单行，而是为每一行返回一个结果。常见的窗口函数包括ROW_NUMBER()、RANK()、SUM() OVER()等。
子查询则是嵌套在其他查询中的查询语句，在分组统计场景中，通常会先通过子查询计算分组聚合结果，再和主表进行关联得到最终数据。
典型场景示例对比
假设我们有一张order_table表，存储了用户订单信息，结构如下：
CREATE TABLE order_table (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL,
order_amount DECIMAL(10,2) NOT NULL,
order_date DATE NOT NULL
);
需求是查询每个用户的订单金额，以及该订单在用户所有订单中的排名。我们分别用子查询和窗口函数实现。
子查询实现方式
SELECT
t1.user_id,
t1.order_amount,
t1.order_date,
t2.rank_num
FROM order_table t1
LEFT JOIN (
SELECT
id,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_amount DESC) AS rank_num
FROM order_table
) t2 ON t1.id = t2.id;
上述写法中，子查询先对全表计算窗口排名，再和主表通过id关联，相当于对表做了两次扫描。
窗口函数直接实现方式
SELECT
user_id,
order_amount,
order_date,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_amount DESC) AS rank_num
FROM order_table;
窗口函数写法只需要一次全表扫描，就可以直接为每一行计算出对应的排名结果。
执行计划层面的差异分析
我们可以通过EXPLAIN命令查看两种写法的执行计划，直观看到性能差异的原因。
子查询执行计划分析
执行EXPLAIN查看子查询写法的计划，会发现优化器会先处理子查询部分，生成临时表，然后再和主表做关联操作。临时表的创建和关联操作都会带来额外的IO和CPU消耗，尤其是当数据量较大时，临时表可能还会写入磁盘，进一步降低性能。
窗口函数执行计划分析
执行EXPLAIN查看窗口函数写法的计划，会发现整个查询只有一次全表扫描，窗口函数的计算是在扫描过程中直接完成的，不需要创建临时表，也不需要额外的关联操作，大大减少了资源消耗。
窗口函数更高效的核心原因
- 扫描次数更少：窗口函数只需要对数据做一次扫描，就可以完成所有计算；而子查询通常需要多次扫描表，或者扫描临时表，IO成本更高。
- 无临时表开销：子查询很多时候需要生成临时表存储中间结果，临时表的创建、维护、销毁都会消耗资源；窗口函数不需要临时表，中间结果直接在内存中处理。
- 优化器支持更好：MySQL 8.0对窗口函数做了专门的优化，执行逻辑更贴合这类场景的需求，而子查询的优化路径相对更复杂，容易出现优化不充分的情况。
使用建议
如果业务场景是MySQL 8.0及以上版本，且需要实现分组排序、累计统计、前后行对比等需求，优先选择窗口函数实现，既能简化代码逻辑，也能获得更好的性能表现。如果使用的是更低版本的MySQL，不支持窗口函数，再考虑使用子查询方案，同时可以通过添加合适索引的方式优化子查询性能。