Oracle 19c真正启用并行需满足前提并显式写Hint：表段>10MB、统计信息准确、未禁用并行、权限充足；有效SQL如SELECT /+ PARALLEL(t,4) / FROM sales t；仅/+ PARALLEL */易被忽略，须配合ALTER SESSION SET PARALLEL_DEGREE_POLICY='AUTO'等会话设置，并通过EXPLAIN PLAN验证PX操作符。
oracle 19c 本身不支持客户端（如 c#）直接“发起并行查询”，所谓“c# 调用并行查询”实际是让 oracle 数据库在执行 sql 时启用并行执行计划（parallel execution plan），关键控制点在 sql hint、会话级设置和连接参数，而非 c# 代码主动调度线程。
怎么写 SQL 才能让 Oracle 19c 真正走并行？
必须显式使用 PARTITION 或 PARALLEL Hint，且满足 Oracle 并行执行的硬性前提：表/索引有足够大的段（默认需 > 10MB）、统计信息准确、目标对象未禁用并行（PARALLEL DEGREE 0）、用户有 SELECT ANY TABLE 或对象级 PARALLEL_QUERY 权限。
常见有效写法：
-
SELECT /*+ PARALLEL(t, 4) */ * FROM sales t WHERE amount > 10000;—— 指定表t使用 4 个并行服务器进程 -
SELECT /*+ PARALLEL AUTO */ * FROM customers;—— 交由 Oracle 自动决策并行度（依赖PARALLEL_DEGREE_POLICY=AUTO） - 避免只写
/*+ PARALLEL */（无参数）—— Oracle 19c 默认行为已收紧，很可能被忽略
注意：ORDER BY、DISTINCT、窗口函数等操作可能抑制并行，需结合 EXPLAIN PLAN 验证是否真生成 PX COORDINATOR / PX SEND 等并行操作符。
连接字符串里哪些参数影响并行执行？
Oracle 客户端（ODP.NET Core / Managed ODP.NET）本身不控制并行，但连接字符串中的参数会影响会话能否启用并行：
-
Connection Timeout=30不影响并行，但并行查询若超时会报ORA-01013: user requested cancel of current operation -
Pooling=true是必须的——并行执行需复用连接池中已初始化的会话上下文，否则每次新建连接都丢失会话级并行设置 -
Enlist=false推荐设为false——参与分布式事务（如 MSDTC）会强制禁用并行 - 不要依赖
Statement Cache Size控制并行——它只缓存解析后的语句，不影响执行计划
真正起作用的是连接后执行的会话级命令，例如在 Open() 后立即执行：ALTER SESSION ENABLE PARALLEL DML;（仅对 DML 有效）或 ALTER SESSION SET PARALLEL_DEGREE_POLICY = 'AUTO';。
为什么加了 PARALLEL Hint 却没提速，甚至更慢？
这是最常踩的坑：并行不是万能加速器，Oracle 19c 对并行有严格成本阈值和资源约束。
- 小结果集（PARTITION Hint 被无视
- 系统资源不足：
PARALLEL_MAX_SERVERS设置过低（默认 40），高并发下排队等待，出现enq: PQ - slave reservation等待事件 - I/O 瓶颈：数据文件在单块 SSD 上，多个并行进程争抢磁盘队列，吞吐反而下降
- C# 层误用：用
Command.ExecuteReader()同步读取大结果集，网络或内存拷贝成为瓶颈，掩盖了数据库端并行收益
验证方法：查 V$PQ_SESSTAT 确认会话是否分配了并行服务器；用 DBMS_XPLAN.DISPLAY_CURSOR 看实际执行计划是否含 PARALLEL 操作符；监控 AWR 中 SQL*Net message from client 占比是否异常高。
C# 代码里要避开哪些典型错误？
ODP.NET 的 API 行为与并行强相关，但文档极少明说：
- 别在
OracleCommand上反复设BindByName = true后又用位置参数——可能导致绑定失败，Hint 不生效 - 避免用
OracleDataAdapter.Fill()加载百万行：它内部逐行读取，无法利用并行管道流式返回，应改用OracleDataReader+ 批量处理 - 禁用
CommandBehavior.SequentialAccess时，如果结果集含BLOB/CLOB，并行执行可能退化为串行（因 LOB 定位需顺序访问） - 连接字符串中
Unicode=true是安全的，但若服务端字符集是AL32UTF8且字段含大量中文，PADDED模式可能引发隐式类型转换，使 Hint 失效
真正关键的一点：并行执行计划的生成完全由 Oracle 优化器决定，C# 只负责把带 Hint 的 SQL 发过去，并确保连接上下文干净。任何试图在 C# 层“协调多个并行查询任务”的做法（比如用 Task.Run 包裹多个 ExecuteReader），本质是应用层并发，和 Oracle 的并行执行无关，还容易耗尽连接池和服务器进程。
