OracleParameter设OracleDbType.Clob更快，因其触发流式传输避免内存全载；而Varchar2强制字符串绑定易致GC暂停或OOM。务必显式设Clob类型、用Stream传值、连接串加Unicode=True。
OracleParameter 设置 OracleDbType.Clob 为什么比 OracleDbType.Varchar2 快？
因为 clob 类型在 oracle 客户端驱动中会触发流式传输协议，避免把整个大文本一次性加载进内存再拼 sql；而 varchar2 强制将内容转成字符串后走普通绑定，遇到几 mb 的文本极易触发 gc 暂停或 outofmemoryexception。
实操建议：
- 只要字段定义是
CLOB，OracleParameter.OracleDbType就必须设为OracleDbType.Clob，哪怕你传的是短字符串 - 不要依赖
parameter.Value = "xxx"让驱动自动推断类型——Oracle Data Provider for .NET（ODP.NET）不会根据值长度或数据库元数据反查类型 - 如果用的是
Oracle.ManagedDataAccess（推荐），确保版本 ≥ 19.10，旧版对 CLOB 流式支持有 Bug，可能静默回退成缓存模式
批量插入时怎么传 CLOB 值才不卡住内存？
核心是别用 string 当载体。CLOB 理想输入源是 Stream 或实现了 IBinarySerialize 的类型，这样 ODP.NET 才能分块读取、边读边发。
常见错误现象：Insert into t(clob_col) values (:p1) 批量执行 1000 次，每次传 new OracleParameter("p1", OracleDbType.Clob) { Value = hugeString } —— 这样每条记录都拷贝一遍完整字符串，GC 压力爆炸。
实操建议：
- 用
MemoryStream包装 UTF8 字节数组：new MemoryStream(Encoding.UTF8.GetBytes(content)) - 若内容来自文件，直接用
File.OpenRead(path)，别先File.ReadAllText - 使用
OracleCommand.ArrayBindCount = 1000开启数组绑定，配合OracleParameter.CollectionType = OracleCollectionType.PLSQLAssociativeArray（仅限 PL/SQL 块场景）
为什么用了 OracleDbType.Clob 还报 ORA-01461？
这是最常踩的坑：你设对了类型，但 OracleParameter.Value 仍是一个 string，ODP.NET 在内部转换时发现长度超 4000 字节，又没开 Unicode 支持，就强行截断并抛这个错。
使用场景：尤其在 Windows 默认 ANSI 编码环境、或连接字符串没配 Unicode=True 时高发。
实操建议：
- 连接字符串里必须包含
Unicode=True，否则即使传Stream，驱动也会在某层偷偷转成string再处理 - 检查
OracleParameter.Size：对 CLOB 不需要设（设了也无效），但如果误设成Size = 4000，部分旧版驱动会强制按 VARCHAR2 处理 - 避免混用：同一个
OracleCommand中，不要一部分参数用Clob，另一部分用Varchar2绑定超长内容——驱动可能复用缓冲区逻辑导致类型混淆
Entity Framework Core + Oracle 能不能绕过手动设 OracleDbType.Clob？
不能。EF Core 的 Oracle.EntityFrameworkCore 提供商目前（v7.x）仍把 CLOB 当作普通字符串映射，底层调用 ODP.NET 时未显式指定 OracleDbType.Clob，所以大批量插入含 CLOB 实体时，默认走低效路径。
性能影响明显：1000 条记录、每条 CLOB 平均 50KB，纯 EF Core 插入耗时可能比手写 OracleCommand + 正确 CLOB 参数慢 3–5 倍。
实操建议：
- 对性能敏感的批量 CLOB 插入，放弃 EF Core SaveChanges，改用原生
OracleCommand - 若必须用 EF Core，可临时把 CLOB 属性映射为
byte[]，并在OnModelCreating中用HasColumnType("BLOB")，再靠数据库触发器或视图转 CLOB（不推荐，增加维护成本） - 关注 Oracle 官方示例库 中
BatchInsertWithClob.cs的写法，他们只在原生 API 场景下保证 CLOB 流式正确性
真正难的不是设那个枚举值，而是从数据源头开始控制载体类型——String 是最方便的陷阱，Stream 才是 CLOB 的自然归宿。
