PL/SQL函数在SQL中逐行调用引发高频上下文切换，造成显著性能开销；PRAGMA UDF仅在12c+且满足纯计算、基础类型、DETERMINISTIC、独立函数等严格条件下生效，复杂逻辑下应重构为SQL层处理。
PL/SQL与SQL引擎之间存在高频上下文切换
每次执行 SELECT my_func(col) FROM t，Oracle 并不是“编译一次、批量调用”。对结果集的每一行，都要从 SQL 引擎切到 PL/SQL 引擎：压参、初始化环境、执行函数体、回传结果、清理上下文。这个切换本身就有固定开销。哪怕函数只写 RETURN x + 1，10 万行就是 10 万次切换。
这种开销在 DBMS_HPROF 或 DBMS_PROFILER 的调用栈里会表现为大量 plsql_exec 等待事件；执行时间也常随行数线性增长，和函数体实际耗时无关。
PRAGMA UDF 并非万能，有严格生效条件
PRAGMA UDF 的作用是让优化器跳过部分 PL/SQL 运行时检查，把函数“内联”进 SQL 执行流——但它只在 12c 及以上版本有效，且必须同时满足：
- 函数必须是纯标量计算：不能含
SELECT INTO、游标、DBMS_OUTPUT、INSERT等任何 SQL 或 I/O 操作 - 参数和返回值只能是基础类型（
NUMBER、VARCHAR2、DATE），不能是记录、集合或对象类型 - 必须显式声明为
DETERMINISTIC（否则被忽略） - 必须是独立函数（
CREATE OR REPLACE FUNCTION），不支持包内函数
常见失效场景：TO_CHAR(SYSDATE, 'YYYYMMDD') 违反确定性；IN OUT 参数不被支持；函数里查了一张配置表，哪怕只读一行，PRAGMA UDF 就直接失效。
函数逻辑稍复杂时，UDF 优化基本无效
一旦函数需要查表、做分支判断、调用其他函数、处理异常或依赖会话状态（如 USER、SYSDATE），PRAGMA UDF 就不起作用。此时真正该做的不是加提示，而是重构：
- 把查表逻辑提前，用子查询或
WITH把数据一次性拉出来，在 SQL 层做 JOIN 或CASE - 若函数用于过滤（
WHERE my_func(col) = 1），优先考虑改写为等价表达式或物化中间结果 - 避免在
SELECT列表中调用多次同一函数，可先用子查询计算一次再引用 - 确认执行计划里是否真卡在函数调用——如果显示
FULL TABLE SCAN，瓶颈可能根本不在函数，而在缺失索引或统计信息过期
容易被忽略的深层影响点
很多人盯着函数体性能，却忽略了两个隐蔽但关键的问题：
- 函数被反复调用时，如果它内部用了未绑定变量的动态 SQL，会触发硬解析，进一步放大开销
- 当函数嵌套在视图或物化视图定义中，其调用行为可能被优化器误判，导致本可下推的过滤条件无法下推
这类问题不会报错，也不会明显报慢，但会在高并发或大数据量场景下突然暴露。验证方式很简单：用 EXPLAIN PLAN 对比加函数前后的执行路径，重点关注 filter 步骤是否出现在访问路径末端，以及 rows 预估是否陡增。
