.NET 6 中 Oracle RAW/BLOB 字段读写变慢的根源是 ODP.NET 21c+ 默认启用流式处理，需在连接字符串中显式设置 Enable Sequence Access=false 并合理配置 Fetch Size 和 OracleParameter.Size。
Oracle RAW 或 BLOB 字段在 .NET 6 中读写变慢的典型表现
不是整体数据库变慢，而是特定含二进制字段（如 raw(2000)、blob）的查询或插入响应时间飙升，尤其在批量操作时 cpu 占用高、网络传输耗时翻倍，oraclecommand.executereader() 或 oraclecommand.executenonquery() 调用明显卡顿。这和 oracle 自身负载无关，同一套 sql 在 .net framework 4.8 下运行正常。
.NET 6 默认启用了 Oracle 客户端的“流式读取”行为
Oracle Data Provider for .NET（ODP.NET）从 21c 开始，在 .NET Core/.NET 5+ 环境中默认启用流式（streaming）处理 BLOB 和大 RAW。这意味着：读取时不再一次性加载到内存，而是通过 OracleBlob.GetStream() 返回延迟流；写入时若未显式调用 Write() 或 Flush()，可能触发多次小块 I/O 和隐式缓冲区拷贝。
- 问题根源：.NET 6 的
System.Data.Common.DbCommand基类对流式结果集的兼容逻辑更严格，导致 ODP.NET 在检测到CommandBehavior.SequentialAccess（即使你没设）时自动降级为流式路径 - 影响场景：使用
OracleCommand.Parameters.Add("p", OracleDbType.Blob).Value = bytes直接赋值 byte[] 时，ODP.NET 会内部包装成流，但未做 buffer 复用，反复分配临时内存 - 验证方式：抓包看网络层是否出现大量
1~4KB的碎包，或用 dotMemory 查看堆中频繁生成OracleInternal.Common.StreamBuffer实例
ODP.NET 版本与连接字符串参数不匹配
常见错误是升级到 .NET 6 后仍沿用旧版 ODP.NET（如 19.11），或新版（21.11+）未关闭默认流式开关。关键参数必须显式控制：
-
Enable Sequence Access = false—— 必须加在连接字符串里，否则 ODP.NET 6+ 会强制启用流式读取 -
Fetch Size = 102400—— 对含RAW列的查询，建议设为 100KB 以上，避免分片拉取（默认 64KB 不够用） - 不要混用
Oracle.ManagedDataAccess.Core和Oracle.ManagedDataAccess：前者针对 .NET Core 编译，后者是传统 .NET Framework 包，混合引用会导致类型解析失败和隐式降级
正确示例连接字符串：Data Source=ORCL;User Id=scott;Password=tiger;Enable Sequence Access=false;Fetch Size=204800;
参数绑定时未预分配 OracleParameter.Size
对于 RAW 字段（尤其是固定长度如 RAW(2000)），.NET 6 下若未设置 OracleParameter.Size，ODP.NET 会按最大可能长度（如 32767）预分配缓冲区，再做截断——这造成大量无效内存拷贝和 GC 压力。
- 写入场景：
param.OracleDbType = OracleDbType.Raw; param.Size = 2000; param.Value = new byte[2000];——Size必须显式设，不能依赖列定义 - 读取场景：用
OracleDataReader.GetBytes()替代直接取byte[]，并传入准确偏移和长度，避免底层触发整块复制 - 注意：
BLOB不适用Size，但需确保OracleCommand.FetchSize足够大，且读取时用GetStream().ReadAsync()配合合理 buffer size（如 64KB）
最易被忽略的是：即使你没动代码，只要 ODP.NET 升级到 21.11+ + .NET 6 运行时，Enable Sequence Access 默认为 true 就足以让所有二进制字段走流式路径——而这个开关在文档里藏得深，报错日志里也完全不体现。
