odp.net性能差主因是默认配置不当：statement cache size=0导致高频硬解析，metadata performance=disabled触发隐式元数据查询，connection lifetime=60强制短命连接；三者需同时显式优化。
ODP.NET Managed 驱动本身不慢，性能差几乎全是配置或用法问题——默认配置下它会主动“自废武功”。
Statement Cache Size=0 导致高频硬解析
这是最隐蔽也最普遍的性能杀手。ODP.NET 默认 Statement Cache Size=0，意味着每次执行 SQL（哪怕只是参数不同）都触发完整硬解析：语法检查、语义分析、执行计划生成。在高并发 DML 场景下，CPU 和 Oracle 共享池压力陡增。
- 必须显式写进连接字符串：
Statement Cache Size=100（推荐 50–200，超 500 反而拖慢查找） - 该参数只在连接字符串中生效，代码里调
OracleConnection.ConnectionString动态改无效 - 不启用时，
SELECT * FROM employees WHERE id = :p1和WHERE id = :p2被视为两条全新语句
Metadata Performance=Disabled 触发隐式系统表查询
每次对新表执行 INSERT/UPDATE/DELETE 前，驱动会自动查 all_constraints、all_cons_columns 等视图获取主键和约束信息——这个查询无法被 EF Core 或 Dapper 拦截，且首次执行必跑。
- 设为
Metadata Performance=Enabled即可跳过该步骤，DML 构造完全基于已知结构 - 不影响
OracleDataReader.GetFieldType()等 SELECT 元数据读取 - 若同时用了
ClientCharacterSet，两个参数共存即可，顺序无关
连接字符串不一致造成池分裂
ODP.NET 按连接字符串**逐字符哈希**分池。一个空格、大小写差异、分号后多换行，都会创建独立池。结果是本该复用 100 个连接的流量，被切成多个小池各占满，NumberOfFreeConnections 持续为 0。
- 禁止拼接：
$"Data Source={host};"或string.Format易引入不可见差异 - 等号前后不能有空格：
Max Pool Size=100✅，Max Pool Size = 100❌（参数被忽略） - 统一小写参数名，服务名全大写或全小写保持一致
Connection Lifetime=60 让连接“活不过一分钟”
设 Connection Lifetime=60 并非保命，而是让每个从池取出的连接只要存活满 60 秒就标记过期；归还时直接关闭，不进池。相当于池永远“养不熟”连接。
- 生产环境应设为
Connection Lifetime=0（禁用生存期控制） -
Connection Timeout=30是建连超时，和 Connection Lifetime 无关，但常被混淆 - 该参数+池分裂+未释放连接，三者叠加时性能抖动会指数级放大
真正卡住人的地方，往往不是某一个参数，而是三个关键项——Statement Cache Size、Metadata Performance、Connection Lifetime——漏掉任意一个，其他优化基本白做。
