.NET 6访问Oracle性能差的主因是ODP.NET默认启用StatementCache引发的元数据查询开销，需配置Statement Cache Size、Metadata Performance和Connection Timeout三项参数，并预热连接。
直接说结论：.net 6 应用访问 oracle 性能差，80% 以上情况不是 sql 写得烂，而是默认启用了 statementcache 触发的元数据查询（比如查 all_constraints、all_cons_columns）在拖慢首请求，同时连接池和参数绑定方式没调对，进一步放大延迟。
为什么插入比 Java/PLSQL 慢几倍？
现象是：同一条 INSERT 在 .NET 6 中执行耗时明显高于其他客户端，但数据库内 SQL_EXECUTION_TIME 只有 1ms。真实瓶颈藏在 .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
这个查询本身不慢，但每换一个表名/所有者就触发一次，且无法被应用层控制。它由 ODP.NET 的元数据发现机制驱动，跟是否用 EF Core 或 Dapper 无关。
- 该行为在 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 场景下的实操要点
即使用了轻量 ORM，底层仍走 ODP.NET，这些细节决定性能上限：
- 用 Dapper 时，**必须显式传参，禁用字符串拼接**：
conn.Execute("INSERT INTO t(x) VALUES (:val)", new { val = x })，否则语句无法进缓存 - EF Core 6+ 使用 Oracle provider（如
Oracle.EntityFrameworkCore）时，确认已启用UseOracleSQLExecutionStrategy()，否则重试逻辑可能干扰缓存命中 - 批量插入别依赖
SaveChanges()循环：改用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（如 INSERT ... SELECT 1 FROM DUAL WHERE 0=1） cmd.CommandText = "INSERT INTO users(id, name) SELECT -1, 'warmup' FROM DUAL WHERE 0=1"; cmd.ExecuteNonQuery();
这能提前加载元数据、填充语句缓存、建立连接池初始连接，把代价摊到启动阶段，而不是让用户扛。
