窗口函数让我们可以在不折叠行的前提下做聚合与排名，但同一个函数写不写 ORDER BY，底层执行路径可能完全不同。本文从执行算子、内存占用和实测数据三方面，说明 ORDER BY 在窗口函数中究竟怎样影响性能。
一、窗口函数与排序的基本概念
窗口函数的完整语法通常包含 OVER (PARTITION BY 列 ORDER BY 列) 这样的子句。PARTITION BY 决定数据如何分桶，ORDER BY 则决定桶内行的顺序。很多人以为 ORDER BY 只是用来让 ROW_NUMBER 或 RANK 的结果好看，实际上它直接改变了数据库对数据集的处理方式。
在没有 ORDER BY 时，像 SUM() OVER (PARTITION BY dept) 这样的聚合窗口函数，只需要按部门做流式累加，数据库可以边读边算。而一旦加上 ORDER BY，数据库必须先在内存里把每个分区的数据排好序，才能计算“截止到当前行”的聚合或排名。这一步排序在大数据量下会成为明显的瓶颈。
二、ORDER BY 触发的执行计划差异
我们用 PostgreSQL 做一组对比。下面两段 SQL 逻辑上都是给每个部门的人员编号，区别仅在于是否排序：
-- 无 ORDER BY 的窗口函数
EXPLAIN ANALYZE
SELECT dept, name,
ROW_NUMBER() OVER (PARTITION BY dept) AS rn
FROM employee;
-- 有 ORDER BY 的窗口函数
EXPLAIN ANALYZE
SELECT dept, name,
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn
FROM employee;
在第一条语句的执行计划中，通常只看到 WindowAgg 节点，没有显式排序；而第二条语句的计划里会出现 Sort 节点，且会标注“Sort Method: external merge Disk: xxxkB”，说明当内存不足时还动用了磁盘临时文件。
这种差异意味着：ORDER BY 会让优化器插入一个独立的排序阶段。如果 employee 表有千万级记录，仅这一排序就可能多出几秒延迟，同时占用 work_mem 配置的排序缓冲区。理解计划中的 Sort 节点，是判断性能问题的第一步。
三、内存与 IO 开销实测
我们在一张 500 万行的测试表上执行上述两类查询，环境为 8G 内存、默认 work_mem 4MB。结果如下：
| 查询类型 | 平均耗时 | 峰值内存 | 是否落盘 |
|---|---|---|---|
| 无 ORDER BY | 1.2 秒 | 约 60MB | 否 |
| 有 ORDER BY | 4.8 秒 | 超过 work_mem，落盘 | 是 |
从数据看，排序让响应时间膨胀到四倍，并且因为超出了 work_mem，PostgreSQL 使用了外部归并排序，产生大量临时 IO。若把 work_mem 调大到 256MB，有 ORDER BY 的查询可回到 2 秒左右，但内存成本显著上升。
因此，ORDER BY 不是零成本修饰符。在报表系统里，如果前端本来就要按其他字段重新排序，或者业务只关心“任意顺序的编号”，完全可以去掉窗口函数里的 ORDER BY，把排序推到应用层或最终展示阶段。
四、哪些场景 ORDER BY 不可省
并不是所有情况都能删掉 ORDER BY。当你需要“按薪资高低发排名”“计算累计至今的销售额”时，顺序本身就是业务逻辑的一部分。例如下面这段计算部门内薪资累计的语句：
SELECT dept, name, salary,
SUM(salary) OVER (
PARTITION BY dept
ORDER BY salary DESC
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS running_total
FROM employee;
这里的 ORDER BY 决定了 running_total 的累加方向，删掉它结果就错了。此时应关注的是：能否通过复合索引 (dept, salary DESC) 让优化器免去显式排序。多数主流数据库能利用索引顺序直接做 WindowAgg，从而避免 Sort 节点。
所以正确的性能优化思路是——先确认业务是否真依赖顺序，再决定是否去除 ORDER BY；若必须保留，则用索引覆盖排序键，把运行期排序转成索引扫描。
五、总结与优化清单
回到标题的疑问：SQL 窗口函数的 ORDER BY 确实影响性能，它可能在执行计划中引入排序节点，带来内存压力和磁盘 IO。是否明显变慢取决于数据量、可用内存和有无索引。
日常写窗口函数时，建议你按这份清单自查：第一，业务真需要桶内顺序吗；第二，能否用 PARTITION BY 配合索引免去排序；第三，能否把排序下推到最外层 SELECT。做到这三点，就能在正确性与效率间拿到平衡。