如何理解BigQuery查询执行计划？三大核心问题求助

1. 如何通过执行计划定位耗时最长的优化点 #

执行计划按层级展示查询的各个执行步骤，重点关注以下维度来定位瓶颈：

• 看每个执行阶段的Duration（耗时）占比：优先锁定占总耗时最高的stage，比如某stage耗时占比超50%，就是核心优化目标。
• 对比Rows Processed和Bytes Processed：如果TableScan这类节点处理的数据量远大于实际需求（比如未加过滤条件、未利用分区/分簇），说明存在无效数据扫描，是优化重点。
• 关注高开销操作节点：Sort、Join、Aggregate这类操作通常是性能瓶颈。比如Join节点耗时高，要检查是否是大表join未用分区键，或数据倾斜导致部分分区处理时间过长；Sort节点耗时高，要确认是否可以通过分簇、提前过滤减少排序数据量。
• 查看并行度：如果某stage并行任务数少但耗时高，说明该步骤无法充分利用并行资源，可能是数据分布不均或操作本身串行（比如全局排序）。

2. 如何获取slot信息并用于查询优化 #

获取slot信息的途径 #

• 查询详情页：在BigQuery控制台的查询历史里，打开目标查询详情，查看Slot time consumed字段，同时在执行计划的每个stage里可以看到该阶段的slot使用情况。
• 系统视图查询：用INFORMATION_SCHEMA.JOBS_BY_PROJECT或JOBS_BY_USER视图，提取total_slot_ms（总slot毫秒数）、slot_time、parallelism等字段，批量分析历史查询的slot使用情况：

  SELECT job_id, total_slot_ms, TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS actual_duration_ms,
         total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS average_parallelism
  FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
  WHERE job_type = 'QUERY' AND end_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  ORDER BY total_slot_ms DESC
  

用slot信息优化查询 #

• 如果average_parallelism（总slot时间/实际耗时）远低于slot配额上限，说明查询未充分利用并行资源，可能存在串行操作（比如全局聚合、未分区的排序）或数据倾斜，需要调整数据分布（比如按join键分簇）或拆分串行步骤。
• 如果某stage的slot使用率低但耗时高，检查是否是数据倾斜：比如join时某几个键对应的数据量远大于其他键，导致部分slot过载、其余slot闲置，这时可以通过预处理大键数据、调整join顺序优化。
• 长期监控slot使用：找出持续占用大量slot的查询，比如频繁扫描全表的报表查询，改为使用分区表、增量刷新减少资源消耗。

3. 实际耗时与总slot时间的区别 #

• 实际耗时：指查询从提交到完成的墙钟时间（用户感知的真实等待时间），取决于查询中最慢的串行步骤、并行资源的利用率。
• 总slot时间：是所有分配给查询的slot的运行时间总和（比如10个slot运行10秒，总slot时间就是100秒），反映的是查询消耗的计算资源总量，也是BigQuery计费的核心依据之一。
• 两者差异的原因：
  • 并行度越高，总slot时间越远大于实际耗时：比如查询充分利用100个slot并行跑了1分钟，实际耗时1分钟，总slot时间就是100分钟。
  • 串行步骤占比高时，两者接近：比如全局排序只能单slot执行，跑了5分钟，实际耗时5分钟，总slot时间也接近5分钟。
  • 数据倾斜会导致两者都偏高：部分slot过载拖慢实际耗时，同时闲置的slot也会贡献少量slot时间，导致总slot时间高于实际耗时但并行度低。

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