PARALLEL Hint 在分区表中未生效，是因为 Oracle 19c 对单分区精确裁剪默认禁用并行；需显式指定分区、改写为范围条件或确保分区大小超阈值（>10MB）。
分区表加 PARALLEL Hint 为什么没生效？
常见现象是写了 select /*+ parallel(t, 4) */ * from sales_part t where dt = date '2025-01-01'，但执行计划里看不到 px 操作符，v$px_session 也为空。根本原因不是分区本身阻止并行，而是 oracle 19c 默认对单个分区扫描不触发并行——即使表启用了并行属性，若查询能精准裁剪到一个分区（如使用分区键等值过滤），优化器会认为“没必要并行”，直接走串行单分区扫描。
必须显式打破这个默认行为：
- 在 Hint 中指定具体分区，例如
SELECT /*+ PARALLEL(t, 4) */ * FROM sales_part t PARTITION (sales_p202501) - 或用
NO_PARTIAL_COMMIT+ 强制全分区扫描（不推荐），更稳妥的是改写为范围/多值条件，让优化器放弃精确分区裁剪，例如WHERE dt BETWEEN DATE '2025-01-01' AND DATE '2025-01-31' - 确保该分区段大小 > 10MB（
DBA_SEGMENTS.BYTES），否则并行启动阈值不满足
分区表上 ALTER TABLE PARALLEL 和 Hint 的优先级怎么算？
Oracle 19c 的并行度决策是三级叠加：对象级（表/分区）→ 语句级（Hint）→ 会话级（ALTER SESSION SET PARALLEL_DEGREE_POLICY）。其中 Hint 优先级最高，但仅当它明确覆盖目标对象时才生效。
例如：ALTER TABLE sales_part PARALLEL 8 设置了整个表的默认并行度；但如果你写 SELECT /*+ PARALLEL(t, 2) */ * FROM sales_part t，实际 DOP 就是 2；而如果只写 SELECT /*+ PARALLEL(t) */ * FROM sales_part t（无参数），Oracle 19c 已收紧策略，大概率忽略该 Hint，回退到表级 DEGREE=8 或会话策略。
关键细节：
- 分区表可对单个分区单独设并行度：
ALTER TABLE sales_part MODIFY PARTITION sales_p202501 PARALLEL 16 -
SELECT /*+ PARALLEL(t, 4) */中的t必须与 FROM 子句中表别名完全一致，大小写敏感（若建表用双引号定义了大小写，则 Hint 也需匹配） - 若分区是
READ ONLY，其DEGREE值会被忽略，Hint 成为唯一有效控制点
跨分区并行扫描时，DOP 是按总数据量算还是每个分区独立算？
Oracle 不按“分区个数 × 单分区 DOP”累加，而是把所有匹配分区视为一个逻辑数据集，统一计算总并行度（DOP）。比如查询命中 3 个分区，Hint 写 /*+ PARALLEL(t, 6) */，Oracle 会尝试分配最多 6 个并行服务进程（P000–P005），由 Query Coordinator（QC）统一分发扫描任务——可能 2 个进程扫第一个大分区，其余 4 个分摊后两个小分区。
但要注意资源瓶颈：
-
PARALLEL_MAX_SERVERS是实例级硬上限，若当前已占用 50 个并行槽位，再发起 DOP=6 的查询，实际可能被降级为 DOP=2 - RAC 环境下，若
PARALLEL_FORCE_LOCAL = TRUE（非默认），则所有 6 个进程强制落在同一节点，无法利用其他空闲节点资源 - 执行后查
V$PQ_TQSTAT，看SERVER_TYPE列是否出现多个Producer行，以及NUM_ROWS分布是否均衡——不均衡说明某些分区数据倾斜严重，拖慢整体
为什么加了 PARALLEL 却比串行还慢？分区表特别容易踩这坑
分区表上并行反效果，核心原因是“小分区 + 高 DOP”引发调度开销压倒收益。比如一个分区只有 20MB，却用 /*+ PARALLEL(t, 8) */，结果 8 个进程争抢同一组数据块缓存，产生大量 gc cr block 2-way（RAC）或 buffer busy waits（单实例）等待。
实操建议：
- 先用
EXPLAIN PLAN FOR看成本估算：若并行路径的COST显著高于串行路径，直接放弃并行 - 对小分区（ 1GB）再考虑 8+，且必须结合
V$RESOURCE_LIMIT确认parallel_max_servers余量充足 - 避免在含
ORDER BY或GROUP BY的查询中盲目加 PARALLEL——这些操作常触发PX COORDINATOR全局归并，反而放大网络/内存压力
真正起效的并行，永远建立在数据量、硬件资源、SQL 结构三者匹配的基础上，分区只是载体，不是加速开关。
