函数必须RETURN且仅返回一个值，适合封装无副作用的计算逻辑；禁止DML/事务操作，参数仅IN模式，需显式指定VARCHAR2长度，高复用函数应输入确定、输出唯一、行为稳定。
RETURN必须有，且只能返回一个值；函数能在 SQL 语句里直接调用——这是它比存储过程更适合封装计算逻辑的根本原因。
为什么不能在函数里写 INSERT 或 COMMIT
Oracle 明确禁止在用户定义函数中执行 DML（INSERT/UPDATE/DELETE）或事务控制语句（COMMIT/ROLLBACK），除非加 AUTHID CURRENT_USER 并显式声明为自治事务（PRAGMA AUTONOMOUS_TRANSACTION），但那会破坏函数“纯计算”的语义，极易引发一致性问题。
常见错误现象：ORA-14551: cannot perform a DML operation inside a query —— 就是因为你在 SELECT 里调用了含 INSERT 的函数。
- 函数设计初衷是“无副作用”的表达式求值，SQL 引擎依赖这点做并行优化和结果缓存
- 如果真要改数据，该用存储过程；如果只是转换、校验、格式化，就用函数
- 想记录日志？用
DBMS_APPLICATION_INFO.SET_MODULE或写到外部表（需UTL_FILE配合目录对象），别在函数里插表
CREATE OR REPLACE FUNCTION 的关键参数陷阱
函数参数默认是 IN 模式，不支持 OUT 或 IN OUT —— 这和存储过程不同。你不能靠参数“传出”多个值，必须靠 RETURN 返回单个结果（可以是对象、集合等复杂类型）。
容易踩的坑：
- 参数名和表字段名同名时，
WHERE col = col会恒为真：必须用WHERE t.col = func.col或重命名参数（如p_col） - 没加
DETERMINISTIC关键字，即使函数逻辑不变，Oracle 也不允许在函数索引或物化视图查询重写中使用它 - 返回
VARCHAR2但没指定长度（如RETURN VARCHAR2），编译会报错；必须写成RETURN VARCHAR2(100)
真正提高复用的三个实操姿势
不是所有逻辑都适合塞进函数。高复用函数通常满足：输入确定、输出唯一、无上下文依赖。
- 把常用字符串处理逻辑抽成函数，比如
normalize_phone(p_in VARCHAR2)统一去空格、加区号、校验位数，之后所有SELECT和报表脚本里直接用normalize_phone(t.phone) - 用
RETURN NUMBER封装业务规则判断，例如is_eligible_for_discount(p_amount NUMBER, p_days_since_reg DATE)，避免在每个报表 SQL 里重复写CASE WHEN ... THEN 1 ELSE 0 END - 对查询结果做轻量聚合再返回，比如
get_dept_headcount(p_dept_id NUMBER)内部只做SELECT COUNT(*) FROM emp WHERE deptno = p_dept_id，调用方不用关心表关联细节
函数复用效果好不好，不取决于写了多少个，而取决于有没有把那些“每次都要抄一遍、改三处才敢跑”的 SQL 片段，变成一个名字清晰、参数明确、行为稳定、能被 SELECT 直接消费的黑盒。别为了复用而复用，更别让函数偷偷摸摸去改数据。
