OracleCommand执行后需调用NextResult()轮转获取多个RefCursor结果集，且所有RefCursor必须按存储过程声明顺序OPEN并注册为Output方向的OracleDbType.RefCursor。
OracleCommand执行后如何获取多个RefCursor结果集
Oracle 存储过程中用 OUT SYS_REFCURSOR 参数返回多个结果集是常见做法，但 .NET 的 OracleCommand 默认只暴露第一个结果集。关键在于：必须显式调用 NextResult() 才能轮转到后续结果集，且所有 RefCursor 必须在存储过程中按顺序 OPEN，顺序错乱或漏开会导致后续结果集读取失败或抛出 InvalidOperationException。
实操要点：
- 确保存储过程里每个
OUT SYS_REFCURSOR都被OPEN（哪怕只是OPEN ref1 FOR SELECT 1 FROM DUAL;），未打开的 RefCursor 在 .NET 端表现为 null，但不会跳过位置 -
OracleCommand.CommandType必须设为StoredProcedure，不能用Text - 所有 RefCursor 参数必须注册为
OracleDbType.RefCursor，方向为Output，否则驱动不识别 - 调用
ExecuteReader()后，第一个结果集可直接读；之后每次调用reader.NextResult()才能进入下一个，返回true表示存在下个结果集
DataReader读取多结果集时的生命周期和资源释放
一个 OracleDataReader 实例可承载全部结果集，但必须顺序消费——不能跳过第2个去读第3个，也不能反复回退。一旦调用 NextResult() 进入新结果集，前一个结果集的读取器就失效了（IsClosed 仍为 false，但再调 Read() 会抛异常）。
容易踩的坑：
- 在某个结果集上未读完就调
NextResult()：不会报错，但未读行会被丢弃（Oracle 驱动不缓存） - 对空结果集（如 RefCursor 对应的查询没返回任何行）仍要调一次
Read()判断，否则NextResult()会失败 - 忘记在 finally 块中
reader.Close()或用using包裹：Oracle 连接池可能因游标未释放而耗尽
使用Oracle.ManagedDataAccess时RefCursor命名是否影响读取
不影响。.NET 驱动按 RefCursor 在存储过程参数列表中的**声明顺序**匹配结果集，与参数名无关。例如存储过程定义为：PROCEDURE get_data(p_out1 OUT SYS_REFCURSOR, p_out2 OUT SYS_REFCURSOR)，那么 reader 第一个结果集对应 p_out1，第二个对应 p_out2，哪怕你在 C# 中把参数加进命令时写成 cmd.Parameters.Add("xxx", OracleDbType.RefCursor).Direction = ParameterDirection.Output;，只要顺序一致就没问题。
注意点：
- 如果中间插入了非 RefCursor 输出参数（比如
OUT NUMBER），它不会占用结果集位置，但会影响参数索引——RefCursor 仍按它们在参数集合里的实际位置（0-based）顺序映射 - 用命名方式添加参数（
Add("@p_out1", ...)）时，务必保证Parameters集合的Count和顺序与存储过程定义严格一致，否则结果集错位
处理大数据量多结果集时的性能和内存考量
每个结果集都通过同一网络连接流式返回，OracleDataReader 默认不缓冲整张表，所以内存压力可控。但要注意：只要任意一个结果集没读完，整个连接就被占用，后续结果集也无法读取，更无法释放连接。
建议做法：
- 对每个结果集使用
while (reader.Read()) { ... }显式消费，避免依赖Load()或DataTable.Load()——后者会强制把当前结果集全加载进内存 - 如果某结果集只需计数或校验结构，可用
reader.GetSchemaTable()获取列信息，再立即NextResult() - 高并发场景下，避免在单次数据库调用中返回过多结果集（比如超过 5 个），易导致连接等待和超时；拆分成多次调用反而更稳定
最常被忽略的是：RefCursor 的打开顺序和 .NET 参数注册顺序必须肉眼核对一致，差一位就会让所有后续结果集数据错位，且很难从错误信息里直接看出原因。
