PX Deq: Execution Msg不是故障而是并行执行中Slave等待QC指令的空闲事件，大量出现暴露DOP失配、资源参数不当或RAC跨节点通信问题。
PX等待事件不是故障信号，而是并行执行框架的通信机制本身在运行——它出现得越多，越说明你正在用并行，但未必说明你用得对。
查不到PX Deq: Execution Msg？先确认是不是RAC环境漏查了gv$视图
单实例下查v$active_session_history可能根本看不到PX等待，因为RAC中QC和Slave进程天然跨节点分布。只查本机视图等于关着灯找钥匙。
- 必须用
gv$active_session_history，且显式分组inst_id比对各节点行为 - 重点看
time_waited（单位微秒），不是COUNT(*)：采样次数高≠真卡住，但MAX(time_waited) > 5000000（即>5秒）是硬指标，代表至少一个Slave被挂起 - 若同一
sql_id在多个inst_id上都有等待，但time_waited差异超过100倍（比如节点2是800ms、节点1是5ms），就是典型并行倾斜，不是SQL慢，是分配不均
PX Deq: Execution Msg高，真问题往往不在SQL而在DOP和资源池配置
这个等待本质是Slave在等QC发指令，属于Oracle归类的idle event，但大量出现时暴露的是上游失配：
-
PARALLEL_MAX_SERVERS设得过大（比如设成256），而物理CPU只有16核，OS线程调度反成瓶颈——降DOP不如先收紧这个参数 - 没关
_parallel_statement_queuing（默认TRUE），资源不足时Slave排队等资源，监控里却仍记作PX Deq: Execution Msg，实际卡点在队列而非通信 - RAC跨实例并行时，IPC延迟被放大，
P1解码后若Sender显示为远程节点ID，就得查网络或共享存储响应时间
PX Deq: Join ACK大量出现？大概率是SGA耗尽或Slave进程残留在OS
这是非空闲等待事件，QC发了join消息但没收到ack，说明Slave根本没起来或起不来：
- 查
v$px_process和OS进程列表（ps -ef | grep ora_p0）是否一致：不一致说明有Slave被kill过但PMON还没清理干净 - 查
V$SGASTAT里free memory是否低于50MB，尤其注意large pool（PARALLEL_AUTOMATIC_TUNING=TRUE时用）或shared pool（=FALSE时用）是否见底 - 该事件没有“立即解决方法”，Oracle靠PMON自动回收，强行重启实例反而可能扩大影响
别只盯着等待事件本身，先看v$pq_tqstat里的数据分发是否倾斜
v$pq_tqstat才是并行执行的真相视图，它直接告诉你每个Slave处理了多少数据、花了多少时间：
- 如果某几行的
BYTES是其他行的10倍以上，说明分区裁剪失效或谓词写了trunc(order_date) = ...这类无法下推的函数 -
QTOTAL（总行数）和QNCPU（CPU数）比值远小于DOP，说明并行度虚高，实际没跑满 - 对比
PX Deq: Execute Reply是否同步飙升：如果它也高，问题在Slave响应慢（I/O或内存不足）；如果只有Execution Msg高，问题在QC派发节奏慢
真正难调的从来不是等待事件名，而是搞不清哪个环节在假等、哪个在真卡——PX Deq: Execution Msg看着像空闲，但它背后可能是QC正卡在解析一个带27层嵌套视图的SQL，也可能是某个Slave因分区键函数导致扫了全表却没人告诉它停手。
