1. 为什么JDBC天生处理不了RECORD：先搞懂Oracle类型体系再说

先说个扎心的现实：Oracle的RECORD类型，从设计上就不是给外部程序用的。

我早年第一次在项目里遇到这个需求时，心里也嘀咕过——Java这边封装好的实体类，对应Oracle那边一个RECORD结构体，两边字段名一样，不就能直接传了吗？结果一跑就报PLS-00306: wrong number or types of arguments，根本对不上。后来翻了Oracle官方文档才明白，RECORD是PL/SQL引擎私有的复合类型，它只在数据库会话内部存在，JDBC驱动压根不认识它。你把一个Java对象传给一个只在PL/SQL里定义的结构，数据库那边根本不知道该怎么接。

要理解这个问题的本质，得先分清Oracle的类型分层：

• 标量类型：NUMBER、VARCHAR2、DATE这些，JDBC直接支持，传参收参都没问题。
• SQL对象类型：用CREATE TYPE ... AS OBJECT定义的，带有SQL名称，JDBC可以通过STRUCT或自定义SQLData来映射。
• PL/SQL专用类型：包括RECORD、关联数组（INDEX BY TABLE）、嵌套表（TABLE OF）、VARRAY（可变数组）在包内定义的版本。这些类型没有SQL层面的名字，只存在于PL/SQL块或包体里，JDBC无法直接引用。

我们的目标就是绕开这个限制，把Java的入参转化成Oracle能识别、存储过程能接收的形式。

先看一个典型的报错场景，很多新手一上来就这么写：

假设存储过程定义在一个包里：

CREATE OR REPLACE PACKAGE PKG_WATER AS -- 定义一个RECORD类型，包含水表编号和用量 TYPE WATER_RECORD IS RECORD( METER_ID VARCHAR2(20), CONSUMPTION NUMBER(10,2), READ_DATE DATE ); -- 存储过程：接收一个RECORD，插入用量表 PROCEDURE INSERT_CONSUMPTION(P_WATER IN WATER_RECORD); END PKG_WATER;

Java这边想当然地传参：

CallableStatement cs = conn.prepareCall("{call PKG_WATER.INSERT_CONSUMPTION(?)}"); cs.setObject(1, someJavaObject); // 这里直接setObject一个自定义对象 cs.execute();

这样跑，Oracle会报错，而且报错信息往往很含糊，一会儿PLS-00306（参数类型或个数错误），一会儿ORA-06550（PL/SQL编译错误），其实根因就一个：驱动无法将Java对象转换成PL/SQL引擎内部定义的RECORD。

那怎么办？思路就一条：既然RECORD是PL/SQL私有的，那就让它在SQL层有一个“可沟通”的替身。

我整理了几种主流做法，各有适用场景，但项目里最常用、最稳的是两种：一是把RECORD换成同结构的SQL对象类型，走JDBC的SQLData接口；二是把RECORD转换成关联数组结构，用数组传参。下面逐个讲。

2. 方案一：把RECORD换成SQL对象类型，走STRUCT/SQLData路线

这个方案的核心思想很简单：RECORD不能直接传，那我就在数据库里创建一个同结构的对象类型（CREATE TYPE），让它成为RECORD的“SQL替身”。反正存储过程关心的是里面的字段值，而不是类型名本身。

2.1 数据库端改造

以刚才的水表用量为例，先在SQL层建一个对象类型：

CREATE OR REPLACE TYPE WATER_OBJ AS OBJECT( METER_ID VARCHAR2(20), CONSUMPTION NUMBER(10,2), READ_DATE DATE );

然后修改存储过程，接收这个对象类型。有两个选择：直接改原存储过程的参数类型，或者包一个重载过程。如果原存储过程参数已经是RECORD，建议保留原过程不动，新建一个“门面过程”接收对象类型，在内部完成转换：

CREATE OR REPLACE PACKAGE BODY PKG_WATER AS -- 原过程：接收RECORD PROCEDURE INSERT_CONSUMPTION(P_WATER IN WATER_RECORD) AS BEGIN INSERT INTO WATER_USAGE(METER_ID, CONSUMPTION, READ_DATE) VALUES(P_WATER.METER_ID, P_WATER.CONSUMPTION, P_WATER.READ_DATE); END; -- 新增门面过程：接收SQL对象类型 PROCEDURE INSERT_CONSUMPTION_OBJ(P_WATER_OBJ IN WATER_OBJ) AS L_WATER_RECORD WATER_RECORD; BEGIN -- 字段一一赋值，完成对象转RECORD L_WATER_RECORD.METER_ID := P_WATER_OBJ.METER_ID; L_WATER_RECORD.CONSUMPTION := P_WATER_OBJ.CONSUMPTION; L_WATER_RECORD.READ_DATE := P_WATER_OBJ.READ_DATE; INSERT_CONSUMPTION(L_WATER_RECORD); END; END PKG_WATER;

注意：如果原存储过程不是定义在包里，而是独立的存储过程，那就没法重载，只能新增一个过程或者改原定义。实际项目里，我一般建议直接改原过程参数类型——只要调用方全部走Java，RECORD类型只在包内部使用，不暴露给外部调用。

2.2 Java端实现SQLData接口

数据库改好了，Java端有两个选择：一个是通过java.sql.Struct手动构造结构对象传给驱动，另一个是实现SQLData接口，让驱动自动完成映射。我推荐后者，代码更清晰。

假设Java端有个水表用量的POJO：

public class WaterUsage implements SQLData { private String sqlTypeName = "WATER_OBJ"; // 对应数据库对象类型名 private String meterId; private BigDecimal consumption; private java.sql.Date readDate; @Override public String getSQLTypeName() throws SQLException { return sqlTypeName; } @Override public void readSQL(SQLInput stream, String typeName) throws SQLException { meterId = stream.readString(); consumption = stream.readBigDecimal(); readDate = stream.readDate(); } @Override public void writeSQL(SQLOutput stream) throws SQLException { stream.writeString(meterId); stream.writeBigDecimal(consumption); stream.writeDate(readDate); } }

字段顺序必须和数据库对象类型的属性定义顺序完全一致。readSQL和writeSQL里读写的顺序也不能乱，否则数据会错位——这个坑我后面专门讲。

2.3 调用存储过程的Java代码

public class RecordInvoker { public static void main(String[] args) { String url = "jdbc:oracle:thin:@//localhost:1521/ORCL"; try (Connection conn = DriverManager.getConnection(url, "user", "password")) { WaterUsage water = new WaterUsage(); water.setMeterId("WM001001"); water.setConsumption(new BigDecimal("23.50")); water.setReadDate(new java.sql.Date(System.currentTimeMillis())); try (CallableStatement cs = conn.prepareCall("{call PKG_WATER.INSERT_CONSUMPTION_OBJ(?)}")) { cs.setObject(1, water); cs.execute(); System.out.println("调用成功"); } } catch (SQLException e) { e.printStackTrace(); } } }

就这么简单。关键在于setObject传入的是一个实现了SQLData的对象，Oracle驱动识别到它会调用writeSQL方法，把Java对象转换成数据库的对象类型，再传给存储过程。

2.4 这个方案适合什么场景

用SQLData这条路线，有几个前提条件需要注意：

• 存储过程参数是SQL对象类型（CREATE TYPE定义），不是包内RECORD。如果是包内RECORD，就得像上面那样加门面过程。
• Java对象必须实现SQLData，且getSQLTypeName返回的字符串要和数据库对象类型名完全一致，包括大小写。
• 用CallableStatement.setObject()传参，不能用setString、setInt之类的标量方法。

实测下来，这个方法在连接池场景也稳定，因为SQLData是在驱动层面完成的类型映射，不依赖连接状态。唯一让我踩过坑的是字段类型匹配——比如Oracle的NUMBER映射到Java的BigDecimal没问题，但如果数据库字段是NUMBER(10)，你偏要用Integer，驱动有时会报内部错误，建议统一用BigDecimal。

如果不想手动实现SQLData，也可以用conn.createStruct()手动构造Struct对象，然后setObject传进去，效果一样，但代码会多几行，适合不想改POJO的场景。

3. 方案二：包内RECORD + 关联数组，用集合类型传参

前面说的SQLData方案有一个硬约束：必须新建SQL对象类型。但如果存储过程是别人写的、包内RECORD不能动，或者项目规范不允许建对象类型，那怎么办？

还有一条路：把RECORD换成包内关联数组（INDEX BY），通过数组传参。这个思路比较绕，但很实用，尤其适合传批量数据——比如一次传多行水表用量。

3.1 数据库端准备

包内定义一个关联数组类型，元素就是RECORD结构：

CREATE OR REPLACE PACKAGE PKG_WATER AS TYPE WATER_RECORD IS RECORD( METER_ID VARCHAR2(20), CONSUMPTION NUMBER(10,2), READ_DATE DATE ); -- 关联数组，下标用BINARY_INTEGER（也可以理解为自增序号） TYPE WATER_TABLE IS TABLE OF WATER_RECORD INDEX BY BINARY_INTEGER; -- 接收关联数组的存储过程 PROCEDURE BATCH_INSERT_CONSUMPTION(P_LIST IN WATER_TABLE); END PKG_WATER;

存储过程内部循环插入：

CREATE OR REPLACE PACKAGE BODY PKG_WATER AS PROCEDURE BATCH_INSERT_CONSUMPTION(P_LIST IN WATER_TABLE) AS BEGIN FOR i IN 1..P_LIST.COUNT LOOP INSERT INTO WATER_USAGE(METER_ID, CONSUMPTION, READ_DATE) VALUES(P_LIST(i).METER_ID, P_LIST(i).CONSUMPTION, P_LIST(i).READ_DATE); END LOOP; END; END PKG_WATER;

这时候的关键问题是：JDBC怎么给WATER_TABLE类型传值？

答案是：Oracle JDBC驱动支持将java.sql.Array对象映射到SQL集合类型，但这里的WATER_TABLE是包内关联数组，不是SQL集合类型，直接传会报错。所以JDBC不能直接传关联数组，需要两步走：

1. 在SQL层创建一个对应结构的一维数组类型（VARRAY或嵌套表）。
2. JDBC传入这个SQL数组，存储过程在内部把它逐行拆开，再转成关联数组或RECORD处理。

3.2 创建SQL数组类型

CREATE OR REPLACE TYPE WATER_OBJ AS OBJECT( METER_ID VARCHAR2(20), CONSUMPTION NUMBER(10,2), READ_DATE DATE ); CREATE OR REPLACE TYPE WATER_OBJ_ARRAY AS VARRAY(1000) OF WATER_OBJ;

注意这个VARRAY(1000)的容量限制，实际项目里如果超过1000条，要么改大，要么直接用嵌套表TABLE OF，但嵌套表在JDBC传参时结构稍有不同，我个人建议先用VARRAY，简单直接。

3.3 Java端构造Array对象

Java端不需要再实现SQLData，而是通过Connection.createArrayOf()直接构造数组。但createArrayOf只支持数据库类型名，所以要把Java对象转成Struct：

public class BatchInvoker { public static void main(String[] args) throws SQLException { String url = "jdbc:oracle:thin:@//localhost:1521/ORCL"; try (Connection conn = DriverManager.getConnection(url, "user", "password")) { // 构造多个Struct Object[][] rows = new Object[][]{ {"WM001001", new BigDecimal("23.50"), new java.sql.Date(System.currentTimeMillis())}, {"WM001002", new BigDecimal("18.20"), new java.sql.Date(System.currentTimeMillis())} }; Struct[] structs = new Struct[rows.length]; for (int i = 0; i < rows.length; i++) { structs[i] = conn.createStruct("WATER_OBJ", rows[i]); } // 将Struct数组转为Oracle的SQL数组 Array array = conn.createArrayOf("WATER_OBJ_ARRAY", structs); try (CallableStatement cs = conn.prepareCall("{call PKG_WATER.BATCH_INSERT_CONSUMPTION(?)}")) { cs.setArray(1, array); cs.execute(); System.out.println("批量调用成功"); } } } }

等一下，这里有冲突：我们创建的存储过程参数是包内关联数组WATER_TABLE，JDBC传进去的是SQL数组WATER_OBJ_ARRAY，Oracle会直接认吗？实测会报类型不匹配。所以数据库端还得再加一层转换——让SQL对象数组作为台阶，内部转成RECORD关联数组：

CREATE OR REPLACE PACKAGE BODY PKG_WATER AS PROCEDURE BATCH_INSERT_CONSUMPTION(P_LIST IN WATER_TABLE) AS BEGIN FOR i IN 1..P_LIST.COUNT LOOP INSERT INTO WATER_USAGE(METER_ID, CONSUMPTION, READ_DATE) VALUES(P_LIST(i).METER_ID, P_LIST(i).CONSUMPTION, P_LIST(i).READ_DATE); END LOOP; END; -- 门面过程：接收SQL数组类型，内部转关联数组再调用原过程 PROCEDURE BATCH_INSERT_CONSUMPTION_VIA_SQL_ARRAY(P_ARR IN WATER_OBJ_ARRAY) AS L_LIST WATER_TABLE; BEGIN FOR i IN 1..P_ARR.COUNT LOOP L_LIST(i).METER_ID := P_ARR(i).METER_ID; L_LIST(i).CONSUMPTION := P_ARR(i).CONSUMPTION; L_LIST(i).READ_DATE := P_ARR(i).READ_DATE; END LOOP; BATCH_INSERT_CONSUMPTION(L_LIST); END; END PKG_WATER;

对应的存储过程调用也改成BATCH_INSERT_CONSUMPTION_VIA_SQL_ARRAY：

CallableStatement cs = conn.prepareCall("{call PKG_WATER.BATCH_INSERT_CONSUMPTION_VIA_SQL_ARRAY(?)}"); cs.setArray(1, array); cs.execute();

注意：conn.createArrayOf的第一个参数必须是SQL层面创建的数组类型名，也就是WATER_OBJ_ARRAY，不能写包内的WATER_TABLE。包内关联数组只在PL/SQL内部有效，SQL层看不到。

这个方案适合单次传多行记录的场景，比如批量导入水表抄表数据。但如果只传一行记录，用这种“数组套对象”的方式就有点重了，不如方案一直接。

3.4 VARRAY和嵌套表的区别

提到数组类型，顺便把VARRAY和嵌套表的区别说清楚，因为踩过坑的人都知道这俩在JDBC传参时表现不一样：

如果你不知道数据量多大，用嵌套表更安全；如果数据量可控（比如一次最多几千条），VARRAY简单可靠。JDBC层面，我用ojdbc8和ojdbc11都试过，VARRAY配合createArrayOf一直很稳定，嵌套表在某些版本需要额外设置，没特殊需求就别碰。

4. 方案对比与选型：什么场景用哪个，别拍脑袋

方法不止一种，选起来其实有规律。我按项目里常见的几类需求做了个简单对比：

几个真实项目里容易踩的坑，提前说：

1. 参数顺序和字段顺序别混。无论是SQLData还是Struct，字段顺序必须和数据库端对象属性定义顺序一致。有一次我把READ_DATE和CONSUMPTION顺序写反了，数据没报错，但插进去的日期变成了数字，排查了半小时。
2. getSQLTypeName()返回的类型名大小写。Oracle对象类型名默认大写，你返回"water_obj"可能报ORA-04043，建议全部用大写或在定义时加双引号强制小写，然后Java端保持一致。
3. 驱动版本差别不小。我实测过ojdbc6、ojdbc8、ojdbc11，老的ojdbc6在处理SQLData时某些字段类型会有奇怪行为，比如TIMESTAMP映射成java.sql.Timestamp有时需要额外配置oracle.jdbc.defaultNchar之类的连接属性。能用新驱动就用新的。

5. 排查链路：从报错到跑通的完整排错思路

纸上谈兵容易，真到跑的时候难免出问题。我遇到过几次比较典型的报错，把排查思路完整记录一下，方便后来人对照。

5.1 场景：“PLS-00306：wrong number or types of arguments”

这个报错很常见。我第一次遇到时第一反应是“参数个数不对”，检查半天发现个数没毛病，后来才意识到是类型映射问题。

排查链路：

1. 确认存储过程包是否编译成功。执行SELECT object_name, status FROM user_objects WHERE object_name='PKG_WATER';，如果状态是INVALID，说明包体里有编译错误，先修复。
2. 确认参数类型。查数据字典：SELECT argument_name, data_type FROM all_arguments WHERE package_name='PKG_WATER' AND object_name='BATCH_INSERT_CONSUMPTION_VIA_SQL_ARRAY';，看data_type是不是WATER_OBJ_ARRAY或WATER_OBJ。
3. 检查Java调用的过程名和参数类型是否和存储过程定义一致。特别提醒：如果你在包外调用包过程，SQL写法是{call PKG_WATER.BATCH_INSERT_CONSUMPTION_VIA_SQL_ARRAY(?)}，如果你忘了写包名，Oracle默认会去找独立的存储过程，一看找不到就报PLS-00306。
4. 如果类型名都对，仍然报这个错，检查conn.createArrayOf("WATER_OBJ_ARRAY", structs)里的第一个参数名是否多了空格或大小写不对。

5.2 场景：“ORA-06550：line 1, column 7：PLS-00306”

这个报错通常出现在调用语句解析阶段，也就是CallableStatement的准备阶段就失败了。

排查链路：

1. 用SQL客户端（如DBeaver）直接执行CALL PKG_WATER.BATCH_INSERT_CONSUMPTION_VIA_SQL_ARRAY(?)，如果SQL客户端也报错，说明是数据库端定义问题，与Java无关。
2. 确认Java里prepareCall的字符串里，过程名是否带包名。Oracle的JDBC调用语法是{call 包名.过程名(?)}，如果漏了包名，就会报PLS-00306，因为Oracle在用户模式里找不到同名独立过程。
3. 检查存储过程的参数是否有默认值或OUT参数。如果存储过程声明P_LIST IN WATER_TABLE DEFAULT ...，但你传的数组类型不匹配，也可能报这个错。

5.3 场景：“ORA-22901：cannot create an instance of this object type”

这个报错很怪，翻译成人话就是“Java端传的对象类型名，数据库里找不到对应的SQL对象类型定义”。

排查链路：

1. 确认WATER_OBJ确实创建了：SELECT TYPE_NAME FROM USER_TYPES WHERE TYPE_NAME='WATER_OBJ';
2. 确认WATER_OBJ_ARRAY也创建了：SELECT TYPE_NAME FROM USER_TYPES WHERE TYPE_NAME='WATER_OBJ_ARRAY';
3. Java端conn.createStruct("WATER_OBJ", rows[i])里的类型名写对没有。如果类型名写成了包内的WATER_RECORD，就会报ORA-22901，因为WATER_RECORD不是SQL类型。
4. 连接用户是否有执行权限：GRANT EXECUTE ON WATER_OBJ TO your_user;。有时候类型创建在A用户下，B用户调用存储过程传参时只给了过程的权限，忘了给类型权限，就会出现这个报错。

5.4 场景：“ORA-01484：arrays must be declared with compatible element types”

这个报错出现在createArrayOf的时候，Java端设置的数组元素类型和数据库定义不一致。

排查链路：

1. 检查WATER_OBJ_ARRAY的元素类型是不是WATER_OBJ：

SELECT t1.type_name, t2.attr_name, t2.attr_type_name FROM user_types t1, user_type_attrs t2 WHERE t1.type_name = 'WATER_OBJ_ARRAY' AND t1.type_name = t2.type_name;

2. Java端conn.createStruct("WATER_OBJ", rows[i])里rows[i]的元素类型要和WATER_OBJ的属性类型匹配。比如METER_ID是VARCHAR2(20)，Java端传了Integer，那就会报错。要全部用字符串或与数据库匹配的Java类型。
3. createArrayOf的第一个参数要写数组类型名WATER_OBJ_ARRAY，不要写元素类型名WATER_OBJ。写错了也会报ORA-01484。

5.5 场景：看起来成功了，但数据错位

这个最可怕，因为不报错，但插进去的数据是乱的。比如METER_ID列里存了日期，CONSUMPTION列里存了一串字符。

根源就一个：字段顺序没对齐。

排查链路：

1. 检查WATER_OBJ的属性顺序：SELECT attr_name, attr_type_name FROM user_type_attrs WHERE type_name='WATER_OBJ' ORDER BY attr_no;
2. 对照Java端SQLOutput.writeString()等写出的顺序，以及conn.createStruct()里Object[]数组的元素顺序。
3. 还有一个容易忽略的地方：如果用的是SQLData实现类，readSQL和writeSQL里的读写顺序必须一致，但readSQL是数据库往Java传时用的，writeSQL是Java往数据库传时用的，两边都要和数据库属性顺序对齐。

我当时数据错位，就是因为writeSQL里先写了日期再写用量，但数据库属性顺序是先用量后日期。调完之后再没出过这种问题。

6. 结合业务场景的完整代码示例：抄表数据入库

说了这么多理论，不如看一个稍微完整一点的例子，把上面的方案串起来。场景是智慧水务系统的水表抄表批量入库，Java后端从现场设备拿到一批抄表数据，要调用Oracle存储过程批量写入。

6.1 数据库对象定义

-- 水表用量对象 CREATE OR REPLACE TYPE WATER_OBJ AS OBJECT( METER_ID VARCHAR2(20), CONSUMPTION NUMBER(10,2), READ_DATE DATE ); -- 批量数组 CREATE OR REPLACE TYPE WATER_OBJ_ARRAY AS VARRAY(5000) OF WATER_OBJ;

6.2 存储过程定义

CREATE OR REPLACE PACKAGE PKG_METER AS -- 每户抄表记录结构（业务内部使用） TYPE METER_READING IS RECORD( METER_ID VARCHAR2(20), CONSUMPTION NUMBER(10,2), READ_DATE DATE ); -- 内部关联数组 TYPE METER_READING_LIST IS TABLE OF METER_READING INDEX BY BINARY_INTEGER; -- 接收SQL数组的批量过程（Java调用这个） PROCEDURE BATCH_SAVE_READING(P_DATA IN WATER_OBJ_ARRAY); END PKG_METER;

包体实现：

CREATE OR REPLACE PACKAGE BODY PKG_METER AS PROCEDURE BATCH_SAVE_READING(P_DATA IN WATER_OBJ_ARRAY) AS L_LIST METER_READING_LIST; BEGIN -- 数据校验：为空直接返回 IF P_DATA IS NULL OR P_DATA.COUNT = 0 THEN RETURN; END IF; -- 转成内部RECORD关联数组 FOR i IN 1..P_DATA.COUNT LOOP L_LIST(i).METER_ID := P_DATA(i).METER_ID; L_LIST(i).CONSUMPTION := P_DATA(i).CONSUMPTION; L_LIST(i).READ_DATE := P_DATA(i).READ_DATE; END LOOP; -- 批量插入，用FORALL性能好 FORALL i IN 1..L_LIST.COUNT INSERT INTO METER_USAGE(METER_ID, CONSUMPTION, READ_DATE, CREATE_TIME) VALUES(L_LIST(i).METER_ID, L_LIST(i).CONSUMPTION, L_LIST(i).READ_DATE, SYSDATE); COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK; RAISE; END BATCH_SAVE_READING; END PKG_METER;

这里我用FORALL而不是普通FOR循环，是因为批量插入场景中FORALL是SQL引擎与PL/SQL引擎的批量绑定模式，性能比逐行INSERT高一个量级。数据量大时这个差异非常明显。

6.3 Java端程序

import java.math.BigDecimal; import java.sql.*; import java.util.ArrayList; import java.util.List; public class MeterReadingBatch { public static void main(String[] args) { String jdbcUrl = "jdbc:oracle:thin:@//10.0.0.5:1521/WATERDB"; String username = "water_app"; String password = "water_pass"; // 模拟一批抄表数据 List<Object[]> readings = new ArrayList<>(); readings.add(new Object[]{"WM001001", new BigDecimal("23.50"), new Date(System.currentTimeMillis())}); readings.add(new Object[]{"WM001002", new BigDecimal("18.20"), new Date(System.currentTimeMillis())}); readings.add(new Object[]{"WM001003", new BigDecimal("30.75"), new Date(System.currentTimeMillis())}); try (Connection conn = DriverManager.getConnection(jdbcUrl, username, password)) { // 构建Struct数组 Struct[] structs = new Struct[readings.size()]; for (int i = 0; i < readings.size(); i++) { structs[i] = conn.createStruct("WATER_OBJ", readings.get(i)); } // 构建SQL Array Array sqlArray = conn.createArrayOf("WATER_OBJ_ARRAY", structs); try (CallableStatement cs = conn.prepareCall("{call PKG_METER.BATCH_SAVE_READING(?)}")) { cs.setArray(1, sqlArray); cs.execute(); conn.commit(); System.out.println("批量保存成功，共 " + readings.size() + " 条"); } } catch (SQLException e) { System.err.println("调用存储过程失败: " + e.getMessage()); // 结构化输出错误码，方便定位 while (e != null) { System.err.println("ErrorCode: " + e.getErrorCode() + ", State: " + e.getSQLState()); e = e.getNextException(); } } } }

这套代码我实测下来，在连接池（HikariCP）和直连模式下都能稳定跑，性能上批量5000条数据一次调用基本在一两秒内，比逐条插入快很多。

6.4 存储过程返回RECORD的情况

有时候不只传参，还需要存储过程返回一个RECORD类型的值。这个更麻烦，因为OUT参数如果是包内RECORD，JDBC依然不认识，也取不出来。

解决办法还是一样：把OUT参数改成SQL对象类型。比如存储过程要返回某个水表的用量详情：

CREATE OR REPLACE PROCEDURE GET_METER_READING( P_METER_ID IN VARCHAR2, P_READING OUT WATER_OBJ ) AS BEGIN SELECT WATER_OBJ(METER_ID, CONSUMPTION, READ_DATE) INTO P_READING FROM METER_USAGE WHERE METER_ID = P_METER_ID AND ROWNUM = 1; END;

Java端调用后用Struct取出：

try (CallableStatement cs = conn.prepareCall("{call GET_METER_READING(?, ?)}")) { cs.setString(1, "WM001001"); cs.registerOutParameter(2, Types.STRUCT, "WATER_OBJ"); cs.execute(); Struct struct = (Struct) cs.getObject(2); Object[] attrs = struct.getAttributes(); String meterId = (String) attrs[0]; BigDecimal consumption = (BigDecimal) attrs[1]; Date readDate = (Date) attrs[2]; }

这里registerOutParameter的第3个参数是类型名，如果你的JDBC驱动版本支持，这样写最稳妥。如果不支持，也可以registerOutParameter(2, Types.STRUCT)，然后getObject(2)拿到Struct。

7. 补充心得与几个容易忽略的细节

最后说几点零碎的，但实际工程里最容易因此翻车的细节。

7.1 驱动版本一定要先用新驱动

Oracle JDBC驱动从ojdbc6到ojdbc11，对SQLData和Array的支持差异不小。我当年用ojdbc6跑createArrayOf，遇到了一个诡异问题：传进去的VARRAY元素数量超过100时，存储过程收到的数据顺序会乱。换到ojdbc8和ojdbc11后就没再复现。后来查了一些资料，怀疑是旧驱动在批量绑定时的内存复用BUG。所以如果你还在用老驱动，第一件事就是升级，省得绕半天。

7.2 Connection的autoCommit会影响CLOB/数组事务行为

如果用DriverManager.getConnection默认autoCommit为true，每次execute之后会自动提交事务。批量插入场景建议显式conn.setAutoCommit(false)，处理完成后手动commit，这样一旦中间某条失败还能回滚，避免“插了一半”的尴尬局面。用连接池的时候也要注意，从池里拿出来的连接状态可能被上次调用污染，建议在代码里显式设置。

7.3 存储过程里的提交策略

这里涉及一个团队协作规范：如果存储过程内部有COMMIT，那Java端再conn.commit()就是重复提交，虽然不报错，但会让人困惑。我建议统一约定：事务控制放在Java端，存储过程只做DML，不COMMIT。这样不管存储过程是单条插入还是批量循环，整体事务边界都清晰，出了问题回滚也方便。上面的例子我特意在存储过程里写了COMMIT，只是为了演示，实际项目里请删掉。

7.4 数据字典查类型的SQL模板

排查问题时这组SQL很有用，建议收藏：

-- 查看当前用户下所有对象类型 SELECT TYPE_NAME, TYPE_OID FROM USER_TYPES WHERE TYPECODE = 'OBJECT'; -- 查看对象类型的属性及顺序 SELECT ATTR_NAME, ATTR_TYPE_NAME, ATTR_NO FROM USER_TYPE_ATTRS WHERE TYPE_NAME = 'WATER_OBJ' ORDER BY ATTR_NO; -- 查看数组类型的元素类型 SELECT ELEM_TYPE_NAME, ELEM_TYPE_OWNER FROM USER_COLL_TYPES WHERE TYPE_NAME = 'WATER_OBJ_ARRAY'; -- 查看存储过程实参定义 SELECT ARGUMENT_NAME, DATA_TYPE, IN_OUT FROM ALL_ARGUMENTS WHERE OBJECT_NAME = 'BATCH_SAVE_READING' AND PACKAGE_NAME = 'PKG_METER' ORDER BY POSITION;

每次出问题，先跑这几个查询，能排除一半的“定义不对”类问题，再去看Java代码，效率高很多。

7.5 别忽略PL/SQL包内的依赖关系

如果你在开发中改了包内的RECORD定义，比如加了一个字段，那所有引用这个RECORD的存储过程都会被标记为INVALID，需要重新编译。Java端如果不同步更新SQLData或Struct的元素，就会出现“存储过程编译正常但调用失败”的玄学问题。遇到这种情况，第一时间SELECT object_name, status FROM user_objects WHERE status='INVALID'，把失效对象重新编译一遍。

7.6 扩展思考：如果存储过程接收的是SYS.ANYDATA类型的参数

有些存储过程的参数是SYS.ANYDATA，这种类型可以容纳任意类型的值。理论上RECORD/对象类型都可以包进去，但Java端要构造ANYDATA需要包一层SYS.ANYDATA的构造函数，麻烦且冷门。我只在极少数系统间集成的场景遇到过，日常业务根本用不到，不展开讲。能避开就避开，一旦处理不好就是无数个日夜的排查。

说回正题。这几种方案我用下来，最推荐的还是方案一：SQL对象类型 + SQLData。它最贴近Java的面向对象思维，代码可读性最好，调试也方便——在IDE里直接看到字段的值。方案二适合批量场景，但代码绕了一层，新手维护起来容易懵。但不管用哪种，核心思路必须记住：RECORD是PL/SQL的私有类型，要让它和Java对话，必须在SQL层搭一座桥。理解了这一点，以后遇到再奇葩的类型（嵌套表、嵌套对象、VARRAY套RECORD），都能自己拆解出方案。