Oracle千万级UPDATE必须用原生数组绑定，禁用Dapper单行循环或拼SQL；需手动构造OracleCommand，设ArrayBindCount、参数数组，分批5000–10000行并显式提交。
Oracle批量更新千万级数据，Dapper本身不支持原生批量UPDATE
Dapper 是一个微 ORM，它不提供像 EF 那样的 UpdateRange 或内置批量操作 API。对 Oracle 执行千万级 UPDATE 时，直接循环调用 connection.Execute("UPDATE ...", item) 会触发千万次网络往返和 SQL 解析，必然超时或 OOM。必须绕过 Dapper 的单语句执行模型，改用原生 Oracle 批处理机制。
用 OracleCommand.BatchSize + 参数化数组实现真批量
Oracle 官方驱动（Oracle.ManagedDataAccess）支持数组绑定（Array Binding），这是唯一能扛住千万级 UPDATE 的路径。Dapper 不拦截或破坏这个能力，但你需要跳过它的常规执行方式，手动构造 OracleCommand 并设置 ArrayBindCount 和参数数组。
关键实操点：
- 使用
OracleConnection原生对象，而非仅靠 Dapper 的IDbConnection抽象 - 参数值必须是长度一致的数组（如
string[]、int[]），不能是List或匿名对象 - SQL 中用标准命名参数（
:id、:status），不要用 Dapper 风格的@id - 务必设置
command.ArrayBindCount = data.Length，否则驱动当单行处理 - 单批次建议控制在 5000–10000 行，太大易触发 Oracle PGA 内存不足（ORA-04030）
示例片段：
using (var conn = new OracleConnection(connStr))
{
conn.Open();
using (var cmd = conn.CreateCommand())
{
cmd.CommandText = "UPDATE orders SET status = :status WHERE id = :id";
cmd.Parameters.Add(new OracleParameter(":id", OracleDbType.Int32) { Value = ids });
cmd.Parameters.Add(new OracleParameter(":status", OracleDbType.Varchar2) { Value = statuses });
cmd.ArrayBindCount = ids.Length;
cmd.ExecuteNonQuery(); // 一次调用完成全部更新
}
}
别踩坑：Dapper.QueryMultiple / ExecuteMultiple 在 Oracle 下无效
有人尝试把多条 UPDATE 拼成一批（如 "UPDATE...;UPDATE...;UPDATE..."）再交给 Dapper.ExecuteMultiple，这在 Oracle 中会失败 —— Oracle 不支持分号分隔的批处理语句（除非用 PL/SQL 块封装）。而 Dapper.QueryMultiple 底层依赖 NextResult()，Oracle 驱动不支持多结果集的非查询语句。
常见错误现象：
- 抛出
Oracle.ManagedDataAccess.Client.OracleException: ORA-00911: invalid character（分号被当非法字符） - 静默只执行第一条，其余被忽略（部分驱动版本行为）
- 事务不一致：部分成功、部分失败，且无法回滚整批
结论：放弃所有“拼 SQL 字符串 + ExecuteMultiple”的幻想，老实用数组绑定。
性能与事务边界：分批 + 显式 Commit + NOLOGGING 权衡
千万级更新不是一锤子买卖。即使用了数组绑定，也要拆成子批次，并控制事务大小：
- 每 10000 行提交一次，避免 UNDO 表空间爆满（ORA-30036）
- 确认业务允许脏读？可加
/*+ APPEND */提示（仅 INSERT 有效），UPDATE 无法绕过 REDO，但可考虑临时把表置为NOLOGGING（需 DBA 权限，且备份窗口内有风险） - 避免在 UPDATE 中调用函数（如
SYSDATE、SEQ.NEXTVAL），它们无法向量化执行，会退化为逐行求值 - WHERE 条件字段必须有索引，否则全表扫描 + 数组绑定仍会慢到崩溃
真正卡住的往往不是 Dapper，而是没意识到 Oracle 的批量本质是「客户端数组 → 服务端向量化执行」，中间隔着驱动层的精细配置。
