Oracle中多个OVER子句并存导致性能崩坏，根本原因是各窗口独立执行排序/分组且PARTITION BY与ORDER BY不一致，引发WINDOW SORT膨胀、行数预估失真及临时表空间溢出。
Oracle里多个 OVER 子句并存的报表，性能崩坏往往不是因为写法“错”，而是分析函数互相干扰、窗口定义冲突、执行路径被隐式改写。关键得拆开看每个 OVER 实际干了什么，而不是堆在一起调。
多个 OVER 子句导致执行计划膨胀的典型现象
常见表现是执行计划里出现大量 WINDOW SORT 或 WINDOW BUFFER 操作，Rows 列预估严重失真（比如预估 100 行，实际处理 500 万行），甚至触发临时表空间爆满。根本原因是 Oracle 对每个独立的 OVER 都可能单独走一遍排序或分组流程，尤其当它们的 PARTITION BY 和 ORDER BY 不一致时。
- 检查执行计划：用
DBMS_XPLAN.DISPLAY_CURSOR看Operation列是否密集出现WINDOW SORT，再比对Starts和E-Rows是否成倍放大 - 避免混合不同粒度的
PARTITION BY：例如一个用PARTITION BY dept_id，另一个用PARTITION BY dept_id, region，Oracle 很难复用中间结果 - 确认是否真需要多个窗口：有些需求看似要多个
OVER，其实可以用单个窗口 + 条件聚合替代，比如SUM(CASE WHEN flag=1 THEN amt END) OVER (...)
ORDER BY 在多个 OVER 中引发 ORA-30487 的真实原因
ORA-30487 不是语法错误，而是 Oracle 强制限制：外层 OVER 的 ORDER BY 不能引用内层分析函数的结果。例如 ROW_NUMBER() OVER (ORDER BY SUM(sales) OVER (PARTITION BY month)) 就会报这个错——因为 SUM(...) OVER 是分析函数，其输出不能直接进外层排序键。
- 必须把内层分析函数结果提前物化：用子查询或 CTE 抽出来，再在外层引用，如
SELECT ..., ROW_NUMBER() OVER (ORDER BY monthly_total) FROM (SELECT ..., SUM(sales) OVER (PARTITION BY month) monthly_total FROM t) - 别依赖“看起来像列”的表达式：即使你给内层结果起了别名，只要它带
OVER，就不能出现在外层ORDER BY里 - 注意
RANK()和ROW_NUMBER()在嵌套时行为差异：前者允许重复值，可能导致外层排序键不唯一，进一步影响执行计划稳定性
用 RANGE vs ROWS 控制窗口范围时的性能陷阱
同一个 OVER 子句里，RANGE BETWEEN 和 ROWS BETWEEN 看似只差一个词，但物理执行完全不同：RANGE 要做键值比较和范围扫描，ROWS 只按行号定位。数据稀疏或有大量重复排序键时，RANGE 可能慢几倍甚至触发磁盘排序。
- 优先用
ROWS：除非业务明确要求“值区间”语义（比如“过去 30 天销售额”），否则一律显式写ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW - 警惕隐式
RANGE：如果只写ORDER BY col但没指定ROWS或RANGE，Oracle 默认用RANGE（对数值/日期类型）或ROWS（对字符串），行为不统一 - 测试数据分布：用
COUNT(DISTINCT col)和总行数对比，若重复率 > 30%，RANGE的代价大概率不可控
分区表上多 OVER 报表的裁剪失效问题
在按时间分区的大表上跑多 OVER 报表，常发现执行计划显示 PARTITION RANGE ALL 却只查最近 1 个月数据——说明分区裁剪没生效。根源通常是 OVER 子句里用了无法下推的表达式，比如 TO_CHAR(dt, 'YYYYMM') 或 SUBSTR(dt_str, 1, 6)，让优化器认不出分区键。
- 把分区过滤提到最外层：先用
WHERE dt >= DATE '2026-09-01'缩小数据集，再在子查询里加OVER，而不是在视图或子查询里用函数包裹分区字段 - 避免在
OVER的PARTITION BY或ORDER BY中使用函数：如PARTITION BY TRUNC(dt, 'MM')会阻止裁剪；改用原生字段PARTITION BY dt，再靠外层WHERE控制范围 - 验证裁剪效果：查
V$SQL_PLAN的PARTITION_START/PARTITION_STOP列，确保只访问目标分区 ID，而非KEY或ALL
多个 OVER 并存时，最易被忽略的是统计信息同步问题——哪怕每个子句单独跑都快，合在一起后优化器可能因中间结果行数估算错误，选错连接顺序或排序算法。务必在重构后用 DBMS_STATS.GATHER_TABLE_STATS 更新涉及表的统计信息，且不要跳过 cascade => TRUE 参数。
