先给出一个核心结论：OracleDataAdapter.Update 默认未启用数组绑定，导致批量更新实际退化为逐行执行。要实现批量优化，必须显式设置 OracleCommand.ArrayBindCount > 1，使用位置占位符，传入等长的 object[] 参数数组，并复用同一命令实例。许多开发者首次遇到此问题时，常困惑于代码逻辑正确但性能却异常缓慢。
OracleDataAdapter.Update 为什么慢得像在读硬盘
直接调用 OracleDataAdapter.Update 批量更新数百行数据时，底层会逐条执行单行 UPDATE 语句，走常规 DML 路径，未触发批量优化。这并非代码错误，而是默认行为——未启用数组绑定（Array Binding），每行被作为独立参数传递至 Oracle 数据库。
常见错误现象：Update 耗时随行数线性增长，网络往返次数显著增加，即使将 OracleCommand.BindByName 设置为 false 也无效。通过 SQL Trace 可观察到大量重复的 UPDATE ... WHERE ROWID = :1 语句。
- 必须显式设置
OracleCommand.ArrayBindCount且使其值大于1（通常设为待处理行数，但需注意避免超出OracleConnection.MaxPoolSize的隐含限制） OracleDataAdapter.UpdateCommand必须使用同一个OracleCommand实例，避免每次新建对象- 绑定参数必须使用位置占位符（如
:1、:2），而不能使用命名参数（如:id），否则数组绑定将失效 - 所有待更新字段值需预先组织为一维数组（例如
object[] ids、object[] names），各数组长度一致且与ArrayBindCount匹配
ArrayBindCount 不是设了就生效的魔法开关
设置 ArrayBindCount = 100 并不意味着 Oracle 一定会接受 100 行数据。它仅在满足“同一条 SQL + 同一组绑定参数类型/长度 + 参数数组长度 ≥ ArrayBindCount”时才能真正启用数组绑定，否则会回退至单行执行。
使用场景：适合主键或唯一约束明确、更新逻辑简单（如根据 ID 更新若干字段）、数据已按目标表结构预对齐的场景。不适合动态拼接 WHERE 条件或混合 INSERT/UPDATE/DELETE 的复杂同步。
- 参数数组必须为
object[]类型，不能使用List或 LINQ 查询结果，因为 ODP.NET 无法识别泛型集合 - 字符串字段如存在 null 值，必须使用
DBNull.Value代替null，否则会引发System.ArgumentNullException异常 - 数值类型精度不匹配（例如 C# 的
decimal与 Oracle 的NUMBER(10,2)）可能导致绑定失败，建议统一使用double或显式调用Convert.ToDecimal() - 如果某列允许空值但数组中对应位置填充了
DBNull.Value，那么其他列也必须保持数组长度对齐，不能跳过空缺位置
UpdateCommand 绑定方式决定能不能走数组路径
ODP.NET 的数组绑定仅支持“位置绑定 + 数组参数”，与 ADO.NET 的 DataRow 状态无关。因此，不能期望 OracleDataAdapter.Update(dataTable) 自动完成拆包——它不会主动将 DataTable.Rows 分解为多个 object[] 并传递给 ArrayBindCount。
正确做法是绕过 Update 方法，手动生成命令并设置数组参数：
var cmd = new OracleCommand("UPDATE emp SET name = :1 WHERE id = :2", conn);
cmd.ArrayBindCount = 100;
cmd.Parameters.Add(new OracleParameter("p_name", OracleDbType.Varchar2) { Value = names });
cmd.Parameters.Add(new OracleParameter("p_id", OracleDbType.Int32) { Value = ids });
注意：names 和 ids 都是 object[]，长度为 100，顺序一一对应。
- 不要在循环中反复执行
cmd.Parameters.Clear()再重新添加参数，这会破坏数组绑定的上下文 - 如果 WHERE 条件涉及多个字段（例如
WHERE dept_id = :1 AND status = :2），则需要准备两个长度一致的数组进行分别绑定 OracleCommand.CommandTimeout需要同步调整增大，尽管数组绑定效率高，但批量更新 1000 行仍可能超过默认的 30 秒超时
性能提升并非微小的改进，而是数量级的差距。实测更新 1000 行数据：逐行执行耗时约 8-12 秒（视网络延迟而定），而启用 ArrayBindCount = 1000 后缩短至 0.3-0.6 秒。不过这一结果仅在参数类型稳定、无隐式类型转换且 Oracle 服务端未开启资源限制时成立。
容易被忽视的点：客户端内存占用会明显增加——ODP.NET 将整个数组缓存于本地，例如 10000 行 × 10 字段 × 平均 50 字节 ≈ 5MB，并非小开销。此外，若其中某一行绑定出错（如字符串超长），整个数组绑定将失败，错误信息仅提示“第 X 行第 Y 列”，无法直接定位到具体业务数据。