oracle存储过程必须严格遵循参数声明、select into异常处理、dbms_output配置、事务控制及调用方适配四原则：in参数只读不可赋值，out参数须用变量接收，in out参数需预先初始化；select into必须捕获no_data_found和too_many_rows；dbms_output需显式启用；dml操作须显式commit/rollback；调用方须匹配参数类型与接收方式。
CREATE OR REPLACE PROCEDURE 是写 Oracle 存储过程的起点，但直接套模板容易踩坑——比如参数没声明类型、OUT 参数调用时不传变量、SELECT ... INTO 遇到多行或无数据就崩。真正能跑通的存储过程，得从参数定义、执行逻辑、异常兜底三块一起抠。
IN/OUT/IN OUT 参数怎么声明才不报错
参数声明不是写完就行，关键在类型匹配和调用方式：
- IN 参数默认可省略关键字，但必须传值，且过程内不能改（改了也没用）；
- OUT 参数必须用变量接收，不能传常量或字面量，否则报 PLS-00363: expression 'xxx' cannot be used as an assignment target；
- IN OUT 参数要求调用时已初始化，否则可能触发 ORA-06502: PL/SQL: numeric or value error。
常见错误：把 p_name OUT VARCHAR2 写成 p_name OUT VARCHAR2(50) —— Oracle 不允许在参数里写长度，只支持 VARCHAR2、NUMBER 这类基础类型名。
SELECT INTO 必须处理 NO_DATA_FOUND 和 TOO_MANY_ROWS
SELECT ... INTO 是最常用也最容易翻车的语句：
- 没查到数据 → 触发 NO_DATA_FOUND 异常，不捕获就直接报错退出；
- 查到多行 → 触发 TOO_MANY_ROWS 异常，哪怕你只想要一条，也得加 ROWNUM = 1 或用游标；
- 别指望 IF SQL%ROWCOUNT = 0 THEN —— SELECT INTO 执行失败根本不会进这个判断，它压根不设 SQL%ROWCOUNT。
稳妥做法是：先用 SELECT COUNT(*) 判断是否存在，再查具体字段；或者直接在 EXCEPTION 块里处理两个异常。
DBMS_OUTPUT.PUT_LINE 输出看不见？先开 serveroutput
写了 DBMS_OUTPUT.PUT_LINE('debug') 却看不到输出，不是代码问题，是环境没配：
- SQL*Plus 或 SQL Developer 命令窗口里，必须先执行 SET SERVEROUTPUT ON；
- 在 JDBC 或 Python cx_Oracle 调用时，DBMS_OUTPUT 默认关闭，需显式调用 dbms_output.enable() 并用 dbms_output.get_line() 读取；
- DBMS_OUTPUT 缓冲区默认 20000 字节，大日志会截断，可提前设 DBMS_OUTPUT.ENABLE(1000000)；
- 它只是调试辅助，别把它当返回值用 —— 生产环境通常禁用，靠 OUT 参数或结果集传递数据。
事务控制别漏 COMMIT/ROLLBACK，尤其带 DML 的过程
存储过程里执行 INSERT/UPDATE/DELETE，默认不自动提交：
- 如果过程末尾没 COMMIT，调用者 session 里能看到修改，但一断开就回滚；
- 出错时若没 ROLLBACK，部分 DML 可能已生效，导致数据不一致；
- AUTHID CURRENT_USER 模式下权限检查发生在运行时，DML 失败可能因调用者缺权限，而非过程创建者；
- 别在过程中混用自治事务（PRAGMA AUTONOMOUS_TRANSACTION），除非真需要独立提交 —— 它会让日志、锁、回滚行为变得极难追踪。
写存储过程最常被忽略的，是调用方视角：你定义的 OUT 参数，对方得用变量接；你抛的 RAISE_APPLICATION_ERROR，对方得在应用层捕获；你依赖的表结构或权限，上线前必须确认目标库已同步。过程本身可以很短，但上下游衔接点一个都不能松。
