大数据SQL窗口函数为什么比子查询更省内存？

先说一个核心结论：窗口函数之所以比子查询更省内存，本质上不是因为“少干活”，而是“不重复搭台子”。它只需要一次排序、一次线性遍历，在内存里构建好窗口框架后反复复用；而子查询每处理一行数据，就得重新建临时表、重新排序，复杂度直接往O(N)奔，内存峰值也跟着线性攀升。

窗口函数只建一次临时结构，子查询每行都新建

注意看执行计划里的Using temporary。窗口函数的临时结构是在内存里一次性搭好的窗口框架，整张表的数据只进这个结构一次。但关联子查询走的是DEPENDENT SUBQUERY模式——每处理外层一行，就重新分配一块临时空间，重建筛选条件，再扫描内表。10万行外层数据，就可能触发10万次临时结构创建。MySQL不会复用这些东西，内存峰值自然是直接翻倍。

排序只做一遍，子查询反复排序

窗口函数的Using filesort发生在初始化阶段：按照PARTITION BY + ORDER BY一次性排好序，后续所有窗口计算都基于这个已排序的数据流滑动执行。子查询这边，如果带了ORDER BY或者隐含排序（比如MAX()配合WHERE），每次执行都得重排一次——没有索引的情况下，就是N次磁盘排序，内存缓冲区反复被冲刷。

• 有复合索引(department, salary DESC)时，窗口函数可以直接跳过排序，但子查询还得为每组单独判断是否走索引
• LAG()、LEAD()这类函数依赖排序定义“前一行”，没有ORDER BY就退化为随机行，但子查询无法规避这个逻辑开销

数据不落盘，子查询容易触发磁盘临时表

窗口函数全程在sort_buffer和window_frame内存区域中流式计算，只要总数据量不超过sort_buffer_size和read_rnd_buffer_size之和，就不会写磁盘。子查询呢？单次结果集稍微大一点（比如部门平均薪资涉及几百人），或者内存不太够的时候，就会生成磁盘临时表——这不止吃内存，还把I/O延迟和锁竞争都带进来了。

• MySQL默认的tmp_table_size和max_heap_table_size通常只有64MB，超限就落盘
• 子查询的loops值在EXPLAIN ANALYZE中等于外层行数，这是内存压力最直接的指标

聚合状态共享，子查询各自维护上下文

SUM() OVER (PARTITION BY user_id ORDER BY order_time)在内存中维护一个滑动累加器，同一用户的数据连续到达时，只需要加减当前值。子查询如(SELECT SUM(amount) FROM orders o2 WHERE o2.user_id = o1.user_id)每次都要从头扫描、过滤、累加，完全无法复用前序计算结果，CPU和内存带宽都被重复消耗。

真正容易被忽略的一点是：窗口函数的内存节省，靠的是“不重复建上下文”而非“少算”。当你看到执行计划里Using filesort和Using temporary同时出现且loops=1时，基本可以确认这是最优路径；若子查询的loops显著大于1，内存压力已经实打实地摆在那里了。