PolarDB MySQL 8.0开启ePQ后仍执行串行计划，求助排查

一、优化器成本阈值与统计信息排查 #

• 检查并行成本阈值参数：PolarDB for MySQL通过loose_parallel_cost_threshold控制优化器触发并行的成本门槛，默认值为100000。执行以下命令查看当前值：

  SHOW VARIABLES LIKE 'loose_parallel_cost_threshold';
  

  如果优化器估算的串行执行成本低于该阈值，会拒绝并行计划。可临时调低该参数测试：

  SET SESSION loose_parallel_cost_threshold = 50000;
  

• 验证表统计信息准确性：过时的统计信息会导致优化器低估扫描行数和执行成本。更新orders表的统计信息：

  ANALYZE TABLE orders;
  

  重新执行EXPLAIN或EXPLAIN ANALYZE查看成本估算变化。

二、ePQ适用场景与会话参数检查 #

• 确认查询符合ePQ支持范围：以下场景会阻止ePQ生效：
  • 查询包含FOR UPDATE、LOCK IN SHARE MODE锁语句
  • 使用用户自定义函数（UDF）、存储过程/函数内部的查询
  • 涉及临时表、非可并行化视图
  • 包含非确定性函数（如RAND()、NOW()、UUID()）
  • LIMIT子句指定的返回行数极少（优化器认为串行更高效）
• 检查会话级ePQ开关：执行以下命令确认会话参数是否正常：

  SHOW SESSION VARIABLES LIKE '%parallel%';
  

  确保loose_parallel_execution为ON，loose_max_parallel_degree不为0。
• 验证优化器开关：检查optimizer_switch中是否开启并行执行：

  SHOW VARIABLES LIKE 'optimizer_switch';
  

  确保parallel_execution=on。

三、SQL模式影响排查 #

部分SQL模式会限制ePQ的触发，执行以下命令查看当前会话的SQL模式：

SHOW SESSION VARIABLES LIKE 'sql_mode';

需注意：

• 严格模式（如STRICT_TRANS_TABLES、STRICT_ALL_TABLES）可能导致优化器放弃并行计划，尤其是当查询存在潜在数据一致性风险时
• 若开启READ_ONLY模式，ePQ无法生效（报表查询通常不会开启，但需排除）

四、其他排查方向 #

• 集群资源状态：若集群CPU、内存使用率过高，优化器会判断并行执行会加剧资源竞争，从而选择串行计划。查看集群监控指标确认资源负载。
• 强制并行偏好：设置loose_parallel_preferred=ON可让优化器更倾向于选择并行计划，临时测试：

  SET SESSION loose_parallel_preferred = ON;
  

• 查看详细执行计划：使用EXPLAIN FORMAT=TREE输出，其中会包含优化器拒绝并行的具体原因（如“Parallel execution is not feasible due to non-deterministic functions”）。

内容的提问来源于stack exchange，提问作者Kristen Lee