分析函数可替代pl/sql循环实现秒级响应，适用于单次扫描、无跨行副作用、结果不改变后续前提的运算，如累计求和、移动平均、top-n排序、会话识别等；但递归依赖或需逐行校验场景不适用。
直接用分析函数替代 pl/sql 循环做复杂运算，多数情况下能从分钟级降到秒级——前提是运算本身可向量化，且不依赖行间状态突变。
哪些复杂运算是分析函数能接住的
不是所有“看起来要循环”的逻辑都适合改写。关键看是否满足：单次扫描可推导、无跨行副作用、结果不改变后续计算前提。
- 累计求和、移动平均、同比环比 →
SUM() OVER、AVG() OVER、LAG()完全胜任 - 分组内排序取 Top-N、并列排名 →
ROW_NUMBER()、RANK()、DENSE_RANK()更稳 - 会话识别（按时间戳+间隔合并连续记录）→
LAG()+ 自定义条件判断 + 累计标记，比游标循环快 5–8 倍 - 但涉及递归依赖（如：当前值 = 上一行计算结果 × 1.05）、或需调用自定义 PL/SQL 函数逐行校验的场景，强行套窗口函数反而拖慢执行计划
为什么用分析函数比 FOR LOOP 快
本质是减少 PL/SQL 与 SQL 引擎之间的上下文切换。每次 FETCH 或 UPDATE 进出 PL/SQL 块，都要触发一次硬解析/绑定/执行路径重估；而分析函数在 SQL 层单次完成全部计算，数据全程留在缓冲区，不落地、不传参、不建中间变量。
- 典型反例：
FOR rec IN (SELECT * FROM sales) LOOP v_total := v_total + rec.amount; END LOOP;—— 每行触发一次变量赋值和类型检查，10 万行 ≈ 10 万次开销 - 等效写法：
SUM(amount) OVER ()—— Oracle CBO 在执行计划里直接走聚合节点，底层用 SIMD 指令批处理 - 注意：若分析函数里嵌套子查询（如
COUNT(*) OVER (PARTITION BY dept_id HAVING ...)），语法非法，且说明你本就不该用窗口函数
ORDER BY 在分析函数里不是可选，是强制
漏写 ORDER BY 的窗口定义，Oracle 不报错，但结果不可复现——尤其在并发更新或统计信息过期时，同一语句多次执行可能返回不同累计值顺序。
-
SUM(sales) OVER (PARTITION BY region)→ 无序，累计值顺序随机 -
SUM(sales) OVER (PARTITION BY region ORDER BY sale_date)→ 安全，但需确认sale_date是否唯一；否则补上主键：ORDER BY sale_date, id -
ROWS BETWEEN 1 PRECEDING AND CURRENT ROW比RANGE BETWEEN INTERVAL '1 day' PRECEDING AND CURRENT ROW快得多，后者要对每行做范围扫描，无法利用索引
别在分析函数里塞 PL/SQL 函数
比如写成 my_custom_logic(col1) OVER (PARTITION BY col2)，Oracle 会为每一行单独调用该函数，失去向量化优势，甚至引发隐式类型转换或上下文切换回 PL/SQL 引擎。
- 真正需要自定义逻辑时，优先考虑用纯 SQL 表达（
CASE、DECODE、内置函数组合） - 若必须用函数，确保它是
DETERMINISTIC且已声明为PARALLEL_ENABLE，否则 CBO 可能禁用并行执行 - 实测：含自定义函数的窗口表达式，在 100 万行数据上比纯 SQL 窗口慢 4.7 倍，且无法被物化视图重写
最易被忽略的一点：分析函数输出不能直接用于 WHERE 或 HAVING，必须套一层子查询。写成 SELECT * FROM t WHERE SUM(x) OVER () > 100 会报错 ORA-30483: window functions are not allowed here。
