是，每个OVER子句独立排序，不复用中间结果；应通过CTE预计算序号列并确保ORDER BY含唯一键，或建立复合索引优化。
多个OVER子句会重复计算排序吗
会。每个OVER子句都是独立的窗口定义，即使ORDER BY和PARTITION BY完全相同，数据库也会为每个窗口函数单独执行一次排序（或利用索引），不会自动复用中间结果。这是SQL标准行为，PostgreSQL、MySQL 8.0+、SQL Server、Oracle 都遵循这一逻辑。
如何避免重复排序开销
核心思路是把公共的排序/分组逻辑提前固化，再在上层引用。实际可行路径只有两条：
- 用
CTE（WITH子句）预先计算好ROW_NUMBER()、RANK()等带序号的列，后续直接引用该列，不再写OVER； - 确保
PARTITION BY + ORDER BY字段上有合适复合索引——数据库可能复用索引扫描顺序，跳过内部排序，但不保证所有场景生效。
例如：想同时获取排名、累计求和、前一行值，不要这样写：
SELECT x, ROW_NUMBER() OVER (ORDER BY x) AS rn, SUM(y) OVER (ORDER BY x) AS cumsum, LAG(y) OVER (ORDER BY x) AS prev_y FROM t;
而应改写为：
WITH ranked AS ( SELECT x, y, ROW_NUMBER() OVER (ORDER BY x) AS rn FROM t ) SELECT x, rn, SUM(y) OVER (ORDER BY rn) AS cumsum, LAG(y) OVER (ORDER BY rn) AS prev_y FROM ranked;
注意：ORDER BY rn能复用rn的物理顺序，但前提是rn是严格递增且无重复的——否则仍可能触发二次排序。
ORDER BY字段有重复值时的陷阱
当ORDER BY列存在重复（如多个相同score），不同窗口函数的OVER子句可能因“不确定排序”导致行序不一致，进而让LAG/LEAD、SUM ... RANGE等结果错位。这不是性能问题，而是逻辑错误。
- 显式追加唯一列（如主键）到
ORDER BY中：ORDER BY score, id； - 避免使用
RANGE窗口帧（如SUM(y) OVER (ORDER BY score RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)），它对重复值敏感，优先用ROWS； - 测试时用
SELECT *, ROW_NUMBER() OVER (ORDER BY score), ROW_NUMBER() OVER (ORDER BY score, id)对比两列是否恒等，可快速暴露隐式排序歧义。
不同数据库对排序复用的实际表现
没有通用优化。PostgreSQL 15+ 在部分场景下会对同一查询中多个相同ORDER BY的OVER做排序共享，但仅限于简单ORDER BY且无FILTER或复杂表达式；SQL Server 会尝试重用排序运算符，但遇到LAG和SUM混合时仍常生成两个排序节点；MySQL 8.0 完全不共享，每个OVER都走独立排序流程。所以别依赖数据库“聪明”，主动用CTE拆解才是稳定解法。
真正容易被忽略的是：CTE里的ORDER BY本身不保证输出顺序，必须在最外层再写ORDER BY——否则rn列看似有序，实际执行时可能因并行或优化器改动而乱序。
