PX Deq: Execution Msg大量出现并非故障，而是PQ Slave等待QC指令的天然协调机制，属空闲事件；但高频等待暴露上游问题，如DOP过高、ORDER BY收拢瓶颈、小表误开并行、QC过载或资源参数配置失当。
为什么PX Deq: Execution Msg会大量出现
这不是“出问题了”就一定代表故障，而是并行执行流程中一个天然存在的协调等待——px deq: execution msg本质是pq slave进程在等qc（query coordinator）发指令，比如“开始执行”“继续取数据”“可以退出”这类信号。它被oracle归类为idle event，但大量出现时往往暴露的是上游设计或资源匹配问题。
哪些SQL或配置容易触发高频率等待
常见诱因不是SQL写错，而是并行策略和实际负载脱节：
- 显式强制高DOP：比如用了
/*+ PARALLEL(t, 32) */，但物理CPU只有16核，Slave进程远超可用调度能力，大量进程卡在“等指令”状态 - ORDER BY + 并行组合：当并行排序结果需由QC串行收拢（如
ORDER BY后接LIMIT或客户端fetch限制），排在后面的Slave会早早完成本地排序，却要空等QC轮询完所有Slave才发终止信号 - 小表误开并行：对几万行的表执行
ALTER SESSION FORCE PARALLEL QUERY，Slave启动/通信开销远超实际收益，反而堆满PX Deq: Execution Msg - QC本身过载：如果QC正忙于解析复杂视图、处理大量绑定变量或遭遇Latch争用，它向Slave派发任务的节奏变慢，所有Slave集体卡住
怎么确认是不是真有问题而不是假警报
关键看两点：等待是否伴随CPU异常、是否集中在特定阶段：
- 查
v$session_event里该事件的time_waited占比：如果单次等待ela普遍30%，说明协调效率低，不是空闲而是“假空闲” - 结合
v$pq_tqstat看数据分发是否倾斜：某几个Slave的BYTES远高于其他，它们可能早做完，却因QC未统一收尾而持续等待 - 对比
PX Deq: Execute Reply：如果后者也同步飙升，说明是QC在等Slave回包，问题在Slave响应慢（可能是I/O或内存不足），而非单纯指令延迟 - 注意P1值：若
sleeptime/senderid中高位标识为QC（如解码后Sender = QC），说明Slave确实在等协调器；若显示为其他Slave编号，可能是中间层数据通道堵塞
调优时最容易忽略的细节
很多人直接砍DOP，但真正卡点常藏在更底层：
-
PARALLEL_MAX_SERVERS设得过大，导致Slave进程创建过多，OS线程调度反成瓶颈，此时降DOP不如收紧该参数 - 没关
_parallel_statement_queuing（默认TRUE），当资源不足时，Slave排队等资源而非等指令，监控里却仍记作PX Deq: Execution Msg - 忽略网络延迟：RAC环境跨实例并行时，QC与Slave间IPC消息走私网，若
net.ipv4.tcp_rmem过小，小消息频繁重传，也会表现为长等待 - Trace文件里看到
ela=513这种毫秒级等待，别只盯数字——要连续看10次以上是否稳定在500±50ms，如果是，大概率是QC侧有固定延迟源（如审计日志刷盘阻塞）
真正有效的干预，永远从“谁在等、等什么、为什么等不到”三层拆解，而不是把等待事件当黑盒处理。
