pl/sql中sum/count函数本身不慢，性能瓶颈在于调用方式：避免循环内单行聚合，应将聚合下推至sql层一次性完成；count(*)与count(col)语义不同但性能无差异，关键在where条件是否走索引；隐式类型转换、缺失直方图或误用result_cache才是真瓶颈。
直接结论：PL/SQL 里用 SUM 或 COUNT 函数本身不构成性能瓶颈，真正拖慢的往往是调用方式——比如在循环中反复执行单行聚合、或把聚合塞进 SELECT INTO 配合低效 WHERE 条件；优化核心是「把聚合移到 SQL 层做透，避免 PL/SQL 层补救」。
别在 PL/SQL 循环里写 SELECT SUM(x) INTO v_sum FROM t WHERE id = :i
这是最典型的反模式。每次循环都触发一次硬解析 + 单行驱动 + 索引查找，哪怕表有索引，1000 次循环就是 1000 次逻辑读+上下文切换。
- 改成一次性聚合：
SELECT SUM(x) FROM t WHERE id IN (SELECT COLUMN_VALUE FROM TABLE(my_id_array))，配合BULK COLLECT拿结果 - 若
my_id_array来自外部输入且长度不确定，注意 Oracle 对IN (SELECT * FROM TABLE(...))的估算依赖统计信息——确保目标表的ID列有直方图，否则优化器可能误判为“只返回 1 行”，退化成 NESTED LOOPS - 如果数组超 1000 个元素，
IN子句可能触发表达式膨胀，改用全局临时表（GTT）+JOIN更稳
COUNT(*) vs COUNT(1) vs COUNT(col) 在 PL/SQL 中没区别，但写法影响执行计划
三者语义不同：COUNT(*) 统计行数，COUNT(col) 忽略 NULL；但关键不在函数名，在于它挂在哪条 SQL 上。
- 如果写
SELECT COUNT(*) FROM t WHERE status = 'A' AND created_date > SYSDATE-7，而status和created_date没复合索引，就会全表扫描——此时换COUNT(1)也救不了 - 若只想知道“有没有数据”，用
SELECT 1 FROM t WHERE ... AND ROWNUM = 1配合%FOUND，比COUNT(*) > 0少读全部匹配行 - 在
FORALL场景下，别用COUNT做循环控制变量后立刻FORALL：集合为空时my_tab是NULL，不是空集合，直接FORALL i IN 1..my_tab.COUNT报ORA-06531
聚合结果缓存要谨慎，别默认开 RESULT_CACHE
RESULT_CACHE 对静态报表类查询有效，但对 PL/SQL 中高频、带绑定变量的聚合查询反而有害——缓存键包含所有绑定值，稍有变化就失效，还占共享池内存。
- 仅当聚合 SQL 完全静态（无绑定变量、表数据极少更新）时，才加
/*+ RESULT_CACHE */提示 - 若必须缓存动态聚合，改用包级变量 + 手动 TTL 控制，比如记录上次执行时间戳，30 秒内相同参数直接返回缓存值
- 检查是否误启全局缓存：
SHOW PARAMETER result_cache_mode，生产环境建议保持MANUAL，避免优化器自作主张
最容易被忽略的一点：聚合性能问题往往不是函数本身慢，而是你没意识到 WHERE 条件里的隐式类型转换正在让索引失效——比如 status = 1（数字）查的是 VARCHAR2 字段，导致全表扫描后再过滤。先看 DBMS_XPLAN.DISPLAY_CURSOR 输出里的 Predicate Information，确认是不是 ACCESS 变成了 FILTER。
