.NET 6访问Oracle性能差的主因是ODP.NET默认启用StatementCache引发的元数据查询开销，需配置Statement Cache Size、Metadata Performance和Connection Timeout三项参数，并预热连接。
开门见山，先说核心结论：如果你的 .NET 6 应用访问 Oracle 数据库时性能不佳，别急着去优化 SQL。在超过八成的场景里，问题根源并非 SQL 写得不好，而是驱动层的一个“默认”行为在作祟——ODP.NET 默认启用的 StatementCache 机制，会在背后触发一系列元数据查询（比如查 all_constraints、all_cons_columns 这些系统表），直接拖慢了首次请求的响应速度。如果此时连接池和参数绑定方式再没调对，延迟就会被进一步放大。
为什么插入比 Ja va/PLSQL 慢几倍？
一个典型的现象是：同一条 INSERT 语句，在 .NET 6 应用里执行耗时，明显高于用 Ja va 或 PL/SQL 客户端执行的时间。但诡异的是，你去数据库里查 SQL_EXECUTION_TIME，发现执行时间可能只有 1ms。那么，时间到底耗在哪了？
真正的瓶颈，就藏在 .NET 驱动层。ODP.NET 会在首次执行 DML（数据操作语言）语句之前，自动去查询系统表，生成类似下面这样的元数据查询：
select ac.constraint_name key_name, acc.column_name key_col, :"SYS_B_0" from all_cons_columns acc, all_constraints ac where acc.owner = ac.owner and acc.constraint_name = ac.constraint_name and acc.table_name = ac.table_name and ac.constraint_type = :"SYS_B_1" and ac.owner = :OwnerName and ac.table_name = :TableName order by acc.constraint_name
这个查询本身并不慢，但关键在于，它会在每次遇到新的表名或所有者（Owner）时触发一次，而且应用层代码完全无法控制这个过程。这个行为是由 ODP.NET 底层的元数据发现机制驱动的，跟你用的是 EF Core 还是 Dapper 这类 ORM 框架没有关系。
- 这个行为在 ODP.NET Core（也就是
Oracle.ManagedDataAccess.Core包）里是默认开启的。而 .NET Framework 时代那个已经废弃的System.Data.OracleClient并不支持这个特性。 - 它只在首次执行某张表的 DML 时发生一次，后续因为缓存生效，开销就消失了——这也是为什么在测试环境，尤其是反复执行同一条语句的场景下，常常测不出这个问题。
- 如果你的业务需要高频切换 Schema 或表（比如多租户架构下的分表场景），那么这个开销就会被反复触发和放大，成为性能的持续负担。
必须调整的三个连接字符串参数
要解决这个问题，调整 ODP.NET Core 的连接字符串是关键。下面这三项参数如果不显式设置，其他优化手段的效果会大打折扣：
Statement Cache Size=50：这个参数的默认值是 0（即禁用缓存）。将其设置为 50 到 200 之间，可以显著减少数据库的硬解析次数。但需要注意，值也不是越大越好，如果设置过大（比如超过 500），反而会增加内存压力和缓存查找的开销。Metadata Performance=Enabled：这是解决问题的核心开关。将其设为Enabled后，驱动就会跳过前面提到的那些系统表查询。需要明确的是，这个设置仅影响 DML 语句的元数据获取，对于SELECT语句的列信息获取没有影响。Connection Timeout=15：这个参数有助于避免因网络抖动或数据库监听器响应慢而导致的应用线程被无限期挂起。配合连接池使用，效果更佳。
一个完整的连接字符串示例如下：
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=orcl.example.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCL)));User Id=myuser;Password=mypass;Statement Cache Size=100;Metadata Performance=Enabled;Connection Timeout=15;
Dapper / EF Core 场景下的实操要点
即使你使用了 Dapper 或 EF Core 这类 ORM 框架来简化操作，底层走的依然是 ODP.NET，因此下面这些细节决定了性能的上限：
- 使用 Dapper 时，必须采用显式参数化查询，绝对禁用字符串拼接。正确写法如：
conn.Execute("INSERT INTO t(x) VALUES (:val)", new { val = x })。否则，拼接出来的 SQL 语句无法进入驱动层的语句缓存，每次都是“新语句”。 - EF Core 6+ 使用 Oracle 提供程序（如
Oracle.EntityFrameworkCore）时，请确认已经启用了UseOracleSQLExecutionStrategy()。否则，EF Core 默认的重试逻辑可能会干扰语句缓存的命中。 - 批量插入操作不要依赖循环调用
Sa veChanges()。应该改用OracleBulkCopy（需要引用Oracle.ManagedDataAccess包）或者利用 Dapper 的Execute方法配合数组参数进行批量绑定。 - 避免在循环内部反复
new OracleConnection()。即使有连接池，创建连接对象本身也有开销。应该复用IDbConnection实例，或者使用using语句确保及时归还到连接池。
容易被忽略的“冷启动”陷阱
上线后的第一次请求特别慢、新部署的 Pod 启动后前几秒响应延迟高、灰度发布切流瞬间出现超时……这些问题往往不是代码逻辑的 Bug，而是 ODP.NET 的元数据缓存和语句缓存还没有被“预热”起来。
破解这个困局最简单有效的方式，就是在应用启动时，主动去“触达”那些关键的业务表：
using var conn = new OracleConnection(connStr); conn.Open(); using var cmd = conn.CreateCommand(); cmd.CommandText = "SELECT 1 FROM DUAL WHERE 0=1"; // 这行代码会触发连接的初始化 cmd.ExecuteNonQuery(); // 接着，对业务主表执行一次不会实际插入数据的“空”DML操作 cmd.CommandText = "INSERT INTO users(id, name) SELECT -1, 'warmup' FROM DUAL WHERE 0=1"; cmd.ExecuteNonQuery();
这样一来，就能提前加载好元数据、填充语句缓存、并建立起连接池的初始连接。把性能代价摊到系统启动阶段，而不是让第一个访问的用户来承担。
