分区表并行查询变慢的主因是跨分区数据重分布或串行化瓶颈，尤其在group by/ob不匹配分区键时触发px send qc (random)等操作，导致协调开销远超收益。
分区表上并行查询为何越跑越慢
不是并行本身拖慢性能，而是并行触发了跨分区数据重分布（PX SEND QC (RANDOM)）或串行化瓶颈，尤其在 GROUP BY、ORDER BY 或非分区键聚合时。常见现象是执行计划里出现大量 PX SEND 和 PX RECEIVE 操作，CPU 和 interconnect 网络使用率飙升，但结果集输出极慢。
GROUP BY 不按分区键分组时的并行陷阱
当 GROUP BY 字段 ≠ 分区键（比如按 region 聚合而表按 dt 分区），Oracle 必须把所有匹配分区的数据拉到 coordinator 进程做全局聚合——这一步强制串行化或低效重分布。
- 执行计划中若出现
PX SEND QC (RANDOM)+PX RECEIVE+HASH GROUP BY，说明并行没带来收益，只增加了协调开销 - 用
/*+ USE_HASH_AGGREGATION */可减少内存重分配，但无法绕过数据重分布本身 - 真正解法是改写逻辑：先按分区键过滤+聚合（
GROUP BY dt, region），再外层汇总；或建物化视图预聚合
单分区扫描被强制并行反而降低吞吐
Oracle 19c 对精确裁剪到单个分区的查询（如 WHERE dt = DATE '2025-01-01'）默认禁用并行——因为串行扫描一个分区通常比启动并行进程更轻量。强行加 /*+ PARALLEL(t, 4) */ 反而引入进程调度、内存分配等额外开销。
- 验证方式：查
v$px_session为空，且执行计划无PX操作符 - 若真需单分区并行（比如该分区 >10MB 且 I/O 瓶颈明显），必须显式指定分区：
SELECT /*+ PARALLEL(t, 4) */ * FROM sales_part t PARTITION (sales_p202501) -
ALTER TABLE ... MODIFY PARTITION ... PARALLEL 8设置后，Hint 中的别名t必须与 FROM 子句完全一致（大小写敏感）
并行度设置过高导致资源争抢
在 RAC 环境下，PARTITION 表的并行任务可能跨实例分发，但若 parallel_max_servers 不足或 _parallel_adaptive_max_users 限制过严，并行进程会排队等待，实际并发度远低于 Hint 值，还可能阻塞其他会话。
- 检查当前可用并行槽位：
SELECT COUNT(*) FROM v$px_process WHERE status = 'AVAILABLE' -
parallel_force_local = TRUE会强制所有并行任务落在本地实例，失去 RAC 扩展性，需确认该参数值 - 避免在 OLTP 会话中长期保留并行设置——
NO_PARALLEL不会自动恢复，建议用ALTER SESSION DISABLE PARALLEL DML清理上下文
真实瓶颈往往藏在「看似合理」的并行配置背后：分区裁剪是否精准、聚合维度是否对齐分区键、实例间通信是否饱和、甚至某个分区是否因 MAXVALUE 膨胀成巨无霸——这些细节不排查清楚，加再多并行度也只是把问题从 CPU 挪到网络或内存。
