PARALLEL提示未生效是因为并行查询未触发实例间分发常见原因包括表未启用并行属性、parallel_force_localTRUE、统计信息陈旧、存在无法并行的谓词或ORDER BY导致全局排序瓶颈。为什么 PARALLEL 提示没生效查的还是单实例oracle rac 下全表扫描不跨实例本质是并行查询pq未触发实例间分发。默认情况下即使加了 /* parallel(t 4) */oracle 也可能只在本节点启动并行进程px尤其当表段未启用 parallel 属性、或 parallel_force_local true 时。检查表是否真正支持跨实例并行SELECT degree, instances FROM dba_tables WHERE table_name YOUR_TABLE; —— 若 degree 是 1 或 instances 是 1强制本地执行确认参数SHOW PARAMETER parallel_force_local若为 TRUE必须显式设为 FALSE需 ALTER SYSTEM 或会话级 ALTER SESSION SET parallel_force_local FALSERAC 中真正触发跨实例 PX 的关键是让 coordinator 进程把 slave 分配到其他节点 —— 这依赖于 parallel_instance_group 配置和各节点负载均衡策略不是光靠 hint 就能决定的V$PQ_TQSTAT 显示只有 Q000没看到 Q101/Q201 这类从属进程这说明并行执行根本没有启动或者被降级为串行。常见于统计信息陈旧、优化器估算行数极小、或存在无法并行的谓词如某些 UDF、ROWNUM、非确定性函数。运行前先查执行计划EXPLAIN PLAN FOR SELECT /* PARALLEL(t 8) */ * FROM t WHERE ...;再 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); —— 看 IN-OUT 列是否含 P-PProducer-Consumer或 P-SProducer-Serial避免在 WHERE 子句中使用 SYSDATE、USER、自定义 PL/SQL 函数除非声明为 DETERMINISTIC 且 PARALLEL_ENABLE大表务必确保有最新统计信息DBMS_STATS.GATHER_TABLE_STATS否则优化器可能因低估数据量而放弃并行用 PARALLEL_DEGREE_POLICY AUTO 反而变慢自动并行度策略在 RAC 上容易误判资源水位导致分配过多 slave 占满所有节点 CPU或因等待跨节点消息引入高 gc cr block busy 等待事件实际吞吐反而下降。生产环境更推荐显式控制PARALLEL_DEGREE_POLICY MANUAL配合表级 ALTER TABLE t PARALLEL 8 和会话级 ALTER SESSION FORCE PARALLEL QUERY PARALLEL 8注意 parallel_max_servers 设置 —— RAC 每个实例独立计数若设为 40两节点共 80 个 PX 进程极易挤占后台进程内存监控真实并行消耗SELECT server_name, status, degree, req_degree FROM v$px_session;对比 req_degree请求并行度和 degree实际获得差值大说明资源争用严重全表扫描 ORDER BY 导致大量 TEMP 表空间写入并行排序ORDER BY在 RAC 中默认触发“全局排序”所有节点的 PX 进程需把数据汇总到 coordinator 节点再排网络传输 单点排序成为瓶颈temp 使用暴增且延迟陡升。 WisPaper 复旦大学研发的AI学术搜索工具5分钟内筛选1000篇论文