用TYPE RECORD能解决参数爆炸问题，因其将10+个扁平参数打包为结构化单参数，避免漏传、错序和类型不一致；但RECORD仅限PL/SQL内使用，外部调用需配合SQL OBJECT TYPE并正确注册映射。
oracle 存储过程中“参数过多”不是指代码写得太长，而是调用时传入的绑定变量数量 > 存储过程声明的参数个数，或 execute immediate 中占位符与实际 bind 变量不匹配——最常见、最隐蔽的根源是：用同一个 sql 对象（如 dbms_sql 语句句柄或 .net 的 oraclecommand）反复执行不同参数个数的存储过程，旧参数未清理。
为什么用 TYPE RECORD 能解决参数爆炸问题
当业务逻辑需要传入 10+ 个字段（比如客户资料 + 订单头 + 支付信息），硬编码每个 IN 参数不仅难维护，还极易在调用端漏传、错序、类型不一致。用 TYPE RECORD 把结构打包成单个参数，本质是把“扁平参数列表”转为“结构化输入”。注意：RECORD 是 PL/SQL 类型，不能直接从 JDBC/ODP.NET 传入；必须配合 OBJECT TYPE 或拆包处理。
-
RECORD只能在 PL/SQL 块内定义和使用，无法跨会话或被外部程序直传 - 若需外部调用，得先创建等价的 SQL 对象类型：
CREATE OR REPLACE TYPE cust_input_t AS OBJECT (cust_id NUMBER, name VARCHAR2(100), amt NUMBER(12,2)); - 存储过程中接收该对象：
PROCEDURE process_order(p_in IN cust_input_t) IS ... - JDBC 中需注册
STRUCT，ODP.NET 用OracleObject映射——漏注册类型或字段顺序错，会报ORA-03113或ORA-06550
别把 %ROWTYPE 当 RECORD 用
%ROWTYPE 是对表/游标结构的**强绑定快照**，不是通用容器。一旦源表加字段或改类型，所有引用它的存储过程重编译失败；而 RECORD 完全手动控制字段，和表结构解耦。但代价是：你得自己保证字段名、类型、精度和业务逻辑一致。
- 错误写法：
DECLARE rec employees%ROWTYPE; BEGIN SELECT * INTO rec FROM employees WHERE ...;—— 若查询只选 3 列，INTO会报ORA-00947（值不足），因为rec有 20+ 字段 - 正确写法：显式声明所需字段的
RECORD，或用SELECT col1,col2,col3 INTO rec.col1,rec.col2,rec.col3 - 别在
RECORD里放NOT NULL字段却不初始化——PL/SQL 不自动赋默认值，运行时报PLS-00320
动态 SQL 中参数数量错位的真实原因
用 EXECUTE IMMEDIATE 调用存储过程时，如果拼接了字符串又混用绑定变量，极容易出现“值过多”。例如：EXECUTE IMMEDIATE 'BEGIN my_proc(:a, :b); END;' USING val1, val2, val3; —— 这里 SQL 字符串只声明 2 个占位符，却传了 3 个值，立刻触发 ORA-06550。
- 检查点：
USING后面的变量个数，必须严格等于 SQL 字符串中:xxx出现的次数 - 避免拼接：不要写
'BEGIN my_proc('||val1||','||val2||'); END;'—— 数值转字符串可能丢失精度，且无法绑定DATE/CLOB等类型 - OUT 参数必须用
OUT关键字声明变量，并在USING中明确标注：USING IN val1, OUT v_out - 调试技巧：把动态 SQL 字符串
DBMS_OUTPUT.PUT_LINE打出来，肉眼核对占位符数量
真正麻烦的从来不是怎么定义 RECORD，而是当你要把 Java 里的 Map<string object></string> 映射到 Oracle 的 OBJECT TYPE 时，字段名大小写、空值处理、嵌套对象序列化这些细节没人替你兜底。
