根本原因是PL/SQL与SQL引擎间高频上下文切换；PRAGMA UDF仅对12c+中纯计算、DETERMINISTIC、独立且参数为IN的基础类型函数有效，否则无效。
oracle自定义函数在sql中调用慢，根本原因不是函数本身，而是pl/sql与sql引擎之间的上下文切换开销；pragma udf能缓解，但只对简单、纯计算型函数有效，且仅限12c及以上版本。
为什么每次调用都变慢：上下文切换才是真瓶颈
Oracle执行SELECT my_func(col) FROM t时，并非“一次编译、批量执行”。每行数据都会触发一次从SQL引擎到PL/SQL引擎的完整切换：参数压栈、环境初始化、执行、结果回传、清理——这个过程本身就有固定开销。哪怕my_func只做RETURN x + 1，10万行就要切换10万次。
- 现象：函数体空或仅含简单算术，但整体SQL耗时仍随行数线性增长
- 验证方式：用
DBMS_PROFILER或DBMS_HPROF抓取调用栈，会看到大量plsql_exec等待 - 影响范围：所有版本都存在，12c前尤其明显；12c+引入
PRAGMA UDF正是为压缩这部分开销
PRAGMA UDF到底做了什么：绕过部分PL/SQL初始化流程
PRAGMA UDF不是魔法开关，它告诉优化器：“这个函数足够轻量，允许跳过部分PL/SQL运行时检查，直接以‘类内置函数’方式嵌入SQL执行流”。但它有硬性前提：
- 函数必须是纯标量计算（不能含
SELECT、INSERT、游标、DBMS_OUTPUT等任何SQL或I/O操作） - 参数和返回值只能是基础类型（
NUMBER、VARCHAR2、DATE），不能是记录、对象、集合 - 必须显式声明为
DETERMINISTIC（否则PRAGMA UDF被忽略） - 仅在12c及以上生效；11g及更早版本加了也无效
示例正确写法：
CREATE OR REPLACE FUNCTION calc_tax(p_amt NUMBER) RETURN NUMBER DETERMINISTIC IS PRAGMA UDF; BEGIN RETURN p_amt * 0.13; END;
为什么加了PRAGMA UDF还是没变快：常见失效场景
很多用户加了PRAGMA UDF却没效果，基本卡在这几个点上：
- 函数里有
SELECT ... INTO语句（哪怕只查一个常量表）→ 直接禁用UDF优化 - 用了
TO_CHAR(SYSDATE, 'YYYYMMDD')这类依赖当前时间的表达式 → 违反DETERMINISTIC契约 - 参数类型是
IN OUT或OUT→PRAGMA UDF不支持非IN参数 - 函数被定义在包内（
CREATE PACKAGE BODY），而非独立函数 →PRAGMA UDF只支持独立函数 - 执行计划里依然显示
FULL TABLE SCAN→ 真正瓶颈是底层SQL，不是函数调用本身
比PRAGMA UDF更有效的替代方案
如果函数逻辑稍复杂（比如要查配置表、做条件分支、调用其他函数），PRAGMA UDF基本无效。此时应优先考虑：
- 把函数逻辑内联进SQL：用
CASE WHEN替代DECODE类函数，用JOIN替代查表型函数 - 改用标量子查询缓存：
SELECT (SELECT my_func(t.col) FROM dual) FROM t，利用Oracle自动缓存相同输入结果（最多255个键值对） - 对高频调用的静态数据建物化视图或全局临时表，避免每次重复计算
- 确认是否真需要函数：有时只是习惯性封装，其实用
WITH子句提前聚合更高效
真正棘手的是那些“看起来像纯计算，实则暗藏SQL”的函数——它们既不满足DETERMINISTIC，又无法内联，还绕不开上下文切换。这种函数该砍就砍，别硬扛着加PRAGMA。
