oracle 12c中with function允许在单条sql中内联定义函数，适用于报表查询中需多次复用定制化计算逻辑（如格式化、脱敏、分级判断）且无需跨语句复用的场景，函数仅在当前sql生命周期内有效，不支持dml、事务控制或引用未声明的with查询名。
oracle 12c 允许在 sql 的 with 子句中直接声明函数，不是为了替代 pl/sql 块，而是让纯 sql 场景下能复用逻辑、避免反复写表达式或调用数据库函数——但必须注意：它只在当前 sql 语句生命周期内有效，且不支持包、触发器、存储过程等上下文。
WITH FUNCTION 在什么场景下真正有用
当你需要在单条 SQL 中多次用到同一段计算逻辑（比如格式化日期、脱敏 ID、分级判断），又不想依赖已存在的数据库函数（可能没权限、版本低、或逻辑太定制），WITH FUNCTION 就比写三遍 CASE WHEN 或嵌套子查询更干净。
- 典型适用：报表类查询中需对字段做统一转换，且该转换不跨语句复用
- 不适用：需要事务控制、异常处理、循环、DML 操作的场景——这时必须回到 PL/SQL 块
- 注意：函数体里不能引用当前 SQL 中尚未物化的
WITH查询名（即不能在函数定义里SELECT * FROM t1，除非t1已在函数定义前声明）
为什么 WITH FUNCTION 容易报 ORA-00905 或 ORA-32034
这两个错误几乎都源于语法顺序或引用时机不对。Oracle 对 WITH 中函数/过程的解析非常严格：
-
WITH FUNCTION必须出现在所有WITH query_name AS (...)之前，且只能有一个FUNCTION或PROCEDURE声明 - 函数体内不能出现未声明的表别名或
WITH查询名；反过来，后续WITH查询可以安全引用前面定义的函数 - 如果函数参数类型写成
NUMBER但传入了NULL或字符串，会直接报ORA-06502，而非延迟到执行阶段 - 函数返回值必须显式声明类型，
RETURN VARCHAR2不能简写为RETURN STRING
WITH FUNCTION 和普通函数性能差异在哪
关键不是“快多少”，而是“是否被物化”。WITH FUNCTION 本身不缓存结果，每次被调用都会重新执行函数体；但若函数被用于 WHERE 或 JOIN 条件中，优化器可能将其下推并结合谓词优化——而普通数据库函数（尤其带 RESULT_CACHE）可跨语句复用。
- 函数内含
SELECT查询？不行。WITH FUNCTION只允许纯 PL/SQL 计算逻辑，禁止 SQL DML/DDL - 想让结果“只算一次”？得靠外部
WITH查询块物化数据，再把函数作用于该结果集，例如：WITH data AS (SELECT id, name FROM emp), f AS (SELECT id, my_func(name) n FROM data) SELECT * FROM f - 对比
DECODE或CASE：函数封装可读性更好，但无性能优势；过度封装反而增加解析开销
WITH 子句整体效率提升的关键条件
很多人以为只要加了 WITH 就自动变快，其实不然。Oracle 是否物化（materialize）那个子查询，取决于成本估算和隐含参数 _with_subquery（默认 optimizer），不是写出来就一定走临时表。
- 当子查询被引用 ≥2 次，且数据量中等（几万行内）、过滤性强时，物化收益明显
- 若子查询只被引用 1 次，或含大量
ROWNUM/ORDER BY且无索引支撑，优化器可能选择不物化，甚至改写为内联视图 - 递归
WITH（CONNECT BY替代方案）必须有明确的终止条件，否则报ORA-32044：循环检测失败 - 调试技巧：加
/*+ MATERIALIZE */提示强制物化，但仅当确认临时表空间充足且语句不频繁执行时才用
真正容易被忽略的是：WITH FUNCTION 的作用域仅限当前 SQL 文本，无法被其他会话或同一条语句外的动态 SQL 访问；而它的价值不在性能飞跃，而在把“一段胶水逻辑”锁死在语句内部，避免污染数据库对象命名空间——这对运维交付和 SQL 审计很关键。
