LATERAL 是 SQL 查询级特性，不能用于存储过程体中；它仅在 SELECT、WITH 或 INSERT...SELECT 等上下文中有效，PL/SQL 不识别，误用将报 PLS-00103 错误。
侧视图 LATERAL 不是存储过程语法，不能直接写进 PROCEDURE 体
很多人看到 lateral 在 select 中用得顺手，就想着把它塞进存储过程中当“高级循环”用——这是错的。lateral 是 sql 查询级特性，只在 select、with 或 insert ... select 等上下文中生效；pl/sql 块里不识别它。硬往 begin...end 里写 cross join lateral 会直接报 pls-00103（遇到符号 “lateral”）。
真正该做的，是把原来靠游标或递归拼接实现的“一行变多行”逻辑，从存储过程里抽出来，改写成带 LATERAL 的独立查询语句，再让存储过程调用这个查询——或者干脆用它替代原存储过程。
用 LATERAL 替代传统字符串分割游标
典型场景：表里存了逗号分隔的姓名字段，旧存储过程用 CURSOR + REGEXP_SUBSTR 循环拆分并插入临时表。这种写法要开游标、FETCH、异常处理，还容易漏 CLOSE。
- 改写后只需一条查询：
SELECT t.split_value FROM your_table CROSS JOIN LATERAL (SELECT TRIM(REGEXP_SUBSTR(col, '[^,]+', 1, LEVEL)) AS split_value FROM DUAL CONNECT BY LEVEL - 注意
REGEXP_COUNT必须有，否则CONNECT BY可能无限循环（尤其空字符串或全逗号时） -
TRIM不能省，CSV 字段常带空格，比如'刘备, 貂蝉 ,张飞' - 若字段含换行符或分号等分隔符，正则模式要同步更新，例如
'[^,;\n]+'
嵌套太深？用 WITH + LATERAL 拆解中间层
当原存储过程里有多层子查询嵌套（比如三层以上），且其中某层负责“展开 CSV 字段”，就最适合用 WITH 把 LATERAL 查询具名化。
- 先定义 CTE：
WITH expanded AS (SELECT id, t.split_value FROM A CROSS JOIN LATERAL (... ) t) - 后续 CTE 或主查询直接
JOIN expanded，不再重复写LATERAL子句 - CTE 名称要有业务含义，比如
user_names_split，别叫t1或tmp - Oracle 12c+ 对 CTE 中的
LATERAL支持稳定，但别在 CTE 内部再套一层LATERAL——嵌套LATERAL容易触发解析错误或计划退化
性能和兼容性必须验证的三个点
LATERAL 虽然写起来清爽，但执行计划可能不如预想——尤其数据量大或分隔符不规律时。
- 务必跑
EXPLAIN PLAN FOR，确认是否走了NESTED LOOPS+CONNECT BY，而不是意外触发全表扫描 - 如果原字段经常为空或只有单值，
REGEXP_COUNT返回 0 或 1，CONNECT BY LEVEL 会返回零行——这符合预期，但下游逻辑若假设“至少一行”，就得加 <code>NVL(..., 'N/A')或外层LEFT JOIN - Oracle 12.1.0.2+ 才完整支持
LATERAL；低于此版本（如 11g）会报ORA-00923，此时只能退回MODEL或自定义函数方案
真正麻烦的不是怎么写 LATERAL，而是它让“一行变多行”的逻辑从 PL/SQL 移到了 SQL 层——这意味着原来在存储过程中可控的错误处理（比如跳过非法格式）、日志记录、事务边界，现在都得靠外层应用或包装查询来补足。
