先说一个核心结论：在大数据场景下，窗口函数之所以比子查询更节省内存，本质原因并非“少干活”，而是“不重复搭台子”。它只需一次排序、一次线性遍历，在内存中构建好窗口框架后反复复用；而子查询每处理一行数据，就必须重新建立临时表、重新排序，复杂度直接攀升至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，内存压力已经实实在在地摆在那里了。
