PL/SQL天生适合实现数据库内强事务一致性与高频访问的复杂业务逻辑；应使用命名块（PROCEDURE/FUNCTION）而非匿名块；大数据量用BULK COLLECT+FORALL分批处理；异常须分类处理，禁用WHEN OTHERS THEN NULL；函数严禁DML；关键逻辑是否入库需依事务耦合度与性能要求判断。
PL/SQL 不是“能不能实现复杂业务逻辑”的问题，而是它天生就为这事设计的——只要逻辑发生在 Oracle 数据库内、需要强事务一致性或高频数据访问，PL/SQL 往往比应用层代码更稳、更快、更可控。
用命名块封装逻辑，别写匿名块做核心业务
匿名块（BEGIN ... END;）适合调试或一次性脚本，但线上复杂逻辑必须用 CREATE OR REPLACE PROCEDURE 或 FUNCTION。原因很实际：
- 命名块会被编译后存入数据字典，执行时跳过语法解析，减少硬解析开销
- 调用方只需
EXEC my_proc(...)，不暴露内部变量和 SQL 细节 - DBA 可通过
DBA_SOURCE审计、版本控制工具可管理 DDL 脚本 - 匿名块里一旦出现
COMMIT或ROLLBACK，会破坏调用方的事务边界，极易引发数据不一致
游标处理大数据量时，优先用 BULK COLLECT + FORALL
逐行 FETCH 游标在万级记录以上就会明显拖慢响应——网络往返+上下文切换开销远超 SQL 执行本身。正确做法是批量拉取、批量提交：
-
BULK COLLECT INTO一次取多行到集合（如TYPE t_emp_tab IS TABLE OF employees%ROWTYPE;），避免循环内反复FETCH -
FORALL i IN INDICES OF emp_list SAVE EXCEPTIONS批量INSERT/UPDATE，失败行不会中断整个批次 - 注意内存：默认
BULK COLLECT无上限，大数据量需用LIMIT n分批，比如FETCH c_emp BULK COLLECT INTO emp_list LIMIT 1000; - 别在
FORALL里写SELECT或复杂函数调用——它只加速 DML，不加速计算
异常处理不能只靠 WHEN OTHERS
WHEN OTHERS THEN NULL; 是生产环境最常见也最危险的习惯。真实业务中必须区分错误类型并做针对性响应：
-
NO_DATA_FOUND：查不到是业务常态（如查用户余额），应返回默认值或空结果，不报错 -
TOO_MANY_ROWS：说明SELECT ... INTO匹配了多行，大概率是 WHERE 条件漏了主键或唯一约束，该改逻辑而非吞异常 -
DUP_VAL_ON_INDEX：唯一键冲突，可能需先MERGE或重试，而不是直接抛出 ORA-00001 让应用崩溃 -
WHEN OTHERS必须带RAISE_APPLICATION_ERROR(-20001, '业务上下文: ' || SQLERRM);，否则堆栈丢失，排查时只剩“过程执行失败”六个字
函数里别做 DML，除非你明确要自治事务
FUNCTION 的核心契约是“只读+返回值”。如果在函数体里写了 INSERT 或 COMMIT，会触发两个严重后果：
- 在 SQL 查询中调用该函数（如
SELECT calc_bonus(emp_id) FROM employees）会导致 ORA-14551 错误：“cannot perform a DML operation inside a query” - 若强行加
PRAGMA AUTONOMOUS_TRANSACTION，该函数会开启独立事务，COMMIT后无法回滚——跟主事务完全割裂，极易造成数据状态错乱 - 真有写操作需求，改用
PROCEDURE；若必须从查询中调用，把写逻辑拆到触发器或单独过程，函数只负责计算
PL/SQL，而是判断哪部分逻辑**必须**放在数据库里——比如库存扣减要跟订单插入在同一事务、且响应压在 50ms 内，这种就绕不开 PROCEDURE；而用户头像 URL 拼接这种纯计算，放应用层更灵活。边界模糊时，先测网络延迟和事务耦合度，再决定代码落点。 
