ORDER BY 在窗口函数中变慢是因为强制触发CPU和内存密集型排序操作，即使有索引也通常无法复用，仅当满足严格条件（如联合索引匹配、无FILTER、无计算列等）时才可能跳过排序。
ORDER BY 在窗口函数里为什么让查询变慢
因为窗口函数的 ORDER BY 会强制触发排序操作，而排序是 CPU 和内存密集型任务。即使底层数据已按某列索引有序，只要窗口定义中写了 ORDER BY，PostgreSQL/MySQL 8.0+/SQL Server 等引擎通常仍会执行一次显式排序——除非满足极严格的优化条件（如分区键+排序键完全匹配索引顺序，且无 FILTER 或复杂表达式）。
常见误判是认为“有索引就不用排”，但窗口函数的排序范围是逻辑窗口（比如 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），不是全表，优化器很难复用索引的物理顺序。
哪些 ORDER BY 场景实际不触发排序
只有极少数情况能跳过排序，需同时满足：
-
ORDER BY列与PARTITION BY列构成联合索引的最左前缀，且顺序一致 - 窗口帧（
ROWS或RANGE）为UNBOUNDED PRECEDING TO CURRENT ROW或UNBOUNDED PRECEDING TO UNBOUNDED FOLLOWING - 没有
FILTER子句、没有计算列参与排序（如ORDER BY UPPER(name)必排序） - PostgreSQL 14+ 或 SQL Server 2025 才可能识别这类优化；MySQL 8.0 基本不跳过
替代方案：用索引+应用层聚合代替 ORDER BY 窗口
当只需要累计求和、最大值等简单聚合，且数据可按时间/ID 严格递增写入时，可以绕过窗口函数：
- 建覆盖索引
：
CREATE INDEX idx_events_ts ON events (user_id, created_at) INCLUDE (amount); - 用自连接或 LATERAL 子查询模拟累计逻辑，依赖索引扫描避免排序
- 在应用层分页拉取有序数据后，用 Python/Go 做流式累加（适合实时看板类场景）
- 对高频查询预物化：用
INSERT ... SELECT定期写入带累计字段的宽表
例如 MySQL 中，SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at) 比等价的自连接慢 3–5 倍（实测百万行），尤其当 created_at 有重复值时，RANGE 帧还会引发额外去重开销。
ORDER BY + ROWS vs RANGE 帧的性能差异
ROWS 帧只数行号，RANGE 帧要比较排序值是否“相等”，代价更高：
-
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW在遇到重复排序值时，会把所有同值行一起纳入当前窗口，导致多次回查 - PostgreSQL 对
RANGE默认使用哈希聚合加速，但内存不足时会落盘，IO 暴涨 - 若业务允许，优先用
ROWS并确保排序列唯一（如拼上主键：ORDER BY created_at, id） - SQL Server 中
RANGE窗口无法并行，而ROWS可以
真正难调的不是语法，而是排序值分布——比如 status VARCHAR(20) 作为 ORDER BY 列，90% 值为 'active'，这时 RANGE 帧会让窗口膨胀到不可控大小。
