在Oracle存储过程中，LAG/LEAD只能在SQL语句（如SELECT、游标）中使用，不可直接用于PL/SQL赋值；必须配合ORDER BY，且作用于过滤后的结果集。
直接说结论：在Oracle存储过程中用 LEAD 和 LAG 做跨行计算，和普通SQL里完全一样——它们是标准窗口函数，不依赖PL/SQL块结构，只要写在SELECT里就生效；但必须配 ORDER BY，且不能在纯PL/SQL赋值语句（如 v_var := ...）中直接调用。
为什么存储过程里写 LAG 会报错 ORA-30483
常见错误是把窗口函数当普通标量函数用，比如：
DECLARE v_prev NUMBER; BEGIN v_prev := LAG(salary, 1) OVER (ORDER BY hire_date); -- ❌ 报 ORA-30483：窗口函数不能出现在此上下文中 END;
原因很实在：LAG 和 LEAD 是 SQL 层的分析函数，不是 PL/SQL 可执行语句支持的内置函数。它们只能嵌在 SELECT、INSERT、UPDATE 的查询部分，不能脱离结果集上下文单独求值。
- 必须包裹在
SELECT ... INTO或游标中使用 - 不能在
IF、LOOP内部直接调用，除非该调用属于一个子查询 - 如果想对单行“模拟”前一行逻辑，得先查出有序结果集，再用游标
FETCH+ 变量暂存，效率低且易错
在存储过程中安全使用 LEAD/LAG 的两种写法
核心原则：让窗口函数运行在 SQL 引擎里，结果再交回 PL/SQL 处理。
-
方式一：用
SELECT ... INTO一次性取带偏移字段的单行
适用于已知目标主键、只需当前+相邻行对比的场景，例如查某员工的上月工资：
DECLARE
v_curr_sal NUMBER;
v_prev_sal NUMBER;
BEGIN
SELECT salary, LAG(salary, 1, 0) OVER (ORDER BY salary_month)
INTO v_curr_sal, v_prev_sal
FROM emp_salary
WHERE emp_id = 1001
AND salary_month = '2026-04';
END;
-
方式二：用显式游标遍历带窗口字段的结果集
适合逐行处理趋势、差值、连续性判断（如“是否连续三天登录”）：
DECLARE
CURSOR c_with_lag IS
SELECT login_date,
LAG(login_date) OVER (ORDER BY login_date) prev_date,
LEAD(login_date) OVER (ORDER BY login_date) next_date
FROM user_login
WHERE user_id = 2002;
BEGIN
FOR r IN c_with_lag LOOP
IF r.login_date - r.prev_date = 1 THEN
DBMS_OUTPUT.PUT_LINE('连续登录：' || r.login_date);
END IF;
END LOOP;
END;
- 注意：游标定义里必须含
ORDER BY，否则LAG/LEAD行为不可预测 - 别在游标里写
PARTITION BY后又在循环里忽略分区边界——比如按用户分组，但循环时没检查user_id是否变化，会导致跨用户误比
LAG 和 LEAD 在存储过程中最常踩的坑
不是语法写错，而是语义理解偏差导致逻辑漏洞：
-
OFFSET是“跳过几行”，不是“取第几行”。LAG(col, 2)拿的是当前行往上数第 2 行的值（即前两行），不是“前两行的平均值”或“前两行中最大值” -
DEFAULT值只在越界时生效，比如首行调LAG、末行调LEAD。但它不会帮你补缺失日期——如果数据本身缺 2026-04-02 记录，LAG不会自动插一条 null 或 0，只会拿 2026-04-01 的值（假设排序连续） - 在
WHERE子句里过滤后才执行窗口函数。这意味着：LAG看到的“前一行”是过滤后的结果集里的前一行，不是原始表的前一行。如果过滤条件删掉了中间某条记录，LAG会跨过去连到更早的那条 - 不要在存储过程里反复打开同一游标做多次
LAG计算（比如分别算 1天/7天/30天偏移）——应一次性在 SELECT 中全算好，避免重复解析开销
真正难的从来不是怎么写 LAG(salary, 1)，而是想清楚“这个‘前一行’到底该按什么排序、属于哪个业务分区、越界时默认填什么才不影响下游计算”。这些必须在写存储过程前，用真实数据样本跑一遍裸 SQL 验证逻辑，而不是靠调试 PL/SQL 临时补丁。
