Oracle自定义聚合函数（UDAF）通常比等效PL/SQL实现更慢，因其基于ODCIAggregate的PL/SQL方法需逐行上下文切换，无法媲美内置聚合的C层原生执行；性能优势仅在绕过PL/SQL、用C/JAVA实现时才可能体现。
oracle自定义聚合函数（udaf）在绝大多数场景下**并不比等效的pl/sql实现性能更优**，甚至通常更慢；所谓“性能更优”是常见误解，根源在于混淆了「执行模型」和「调用开销」。
ODCIAggregate 不等于原生聚合性能
Oracle 内置聚合函数（如 SUM、COUNT）由 C 层直接实现，绕过 PL/SQL 引擎，全程在 SQL 执行引擎内完成，无上下文切换、无 PL/SQL 函数调用栈开销。而基于 ODCIAggregate 接口的自定义聚合函数本质仍是 PL/SQL 对象类型，其 ODCIAggregateIterate、ODCIAggregateMerge 等方法仍运行在 PL/SQL 引擎中 —— 每次迭代都触发一次 PL/SQL 调用，对每行数据都要做一次上下文切换。
- 实测中，一个简单累加逻辑的 UDAF 比等价的
SUM()慢 3–8 倍（取决于数据量和 PGA 配置） -
ODCIAggregateMerge在并行查询时才被调用，但合并本身仍是 PL/SQL 运算，无法规避解释执行开销 - 若聚合逻辑含复杂判断（如位运算、条件跳转），PL/SQL 解释器的分支预测失效会进一步放大延迟
真正能提升性能的唯一路径：避免 PL/SQL 调用
如果目标是「高效位与聚合」这类需求（如权限表 BITAND 合并），正确做法不是写 UDAF，而是：
Unified LLM Gateway - One API for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more
下载
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- 用分析函数 + 窗口递归替代：例如
LISTAGG拼接后在应用层解析（适合中小结果集） - 改用纯 SQL 位运算聚合：Oracle 12c+ 支持
BITAND配合MODEL子句或递归WITH实现无 PL/SQL 的逐行位与 - 对固定小集合，用
CASE WHEN展开 +MIN/MAX模拟位与逻辑（适用于 permission_type 枚举值有限） - 若必须复用业务逻辑，优先封装为
DETERMINISTIC标量函数 +RESULT_CACHE，而非 UDAF
为什么有人误以为 UDAF 更快？
典型误导来自两类场景：
- 对比对象错误：拿 UDAF 和「循环游标 +
FETCH+ 手动 BITAND」的 PL/SQL 过程比 —— UDAF 确实更快，但这只是因为避免了 SQL*Plus/OCI 层往返，而非 UDAF 本身高效 - 忽略 PGA 影响：UDAF 的状态对象（如
v_permission_bitand）常驻 PGA，而游标方案频繁分配释放内存；但 PGA 占用高会挤占其他会话资源，实际并发性能反而下降 - 测试数据量太小：在百行以内，UDAF 初始化开销占比高，掩盖了 per-row 的 PL/SQL 开销，造成“启动快=整体快”的错觉
真正需要 UDAF 的场合极少，仅当必须把聚合逻辑下沉到 C/JAVA 层（绕过 PL/SQL）、且该逻辑无法用现有 SQL 功能表达时才值得投入；否则，99% 的情况应优先优化 SQL 写法或索引，而不是造轮子。
