BigQuery同一查询随机生成不同执行计划问题咨询

遇到这种BigQuery里INSERT追加语句执行计划不稳定，还没法靠执行计划拿已插入记录数的问题确实闹心，我给你整理几个实用的排查和解决方向：

一、替代执行计划获取插入行数的可靠方法 #

之前依赖执行计划取记录数的方式失效后，你可以直接通过BigQuery的系统信息视图查询作业的实际插入统计，这是官方认可的稳定方式，不受执行计划变化影响：

SELECT 
  job_id,
  TIMESTAMP_MILLIS(start_time) AS 作业启动时间,
  TIMESTAMP_MILLIS(end_time) AS 作业结束时间,
  statistics.query.statistics.insert.output_rows AS 已追加记录数
FROM 
  `region-你的作业区域`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE 
  job_id IN ('bquijob_6e6a8772_1610d595b56', 'bquijob_5e9c0051_1610d58c352')
ORDER BY 
  start_time DESC;

记得把region-你的作业区域替换成你的BigQuery作业所在的实际区域（比如region-us）。

二、排查执行计划随机变化的原因 #

执行计划不稳定通常和BigQuery查询优化器的决策逻辑相关，你可以从这几个角度排查：

• 刷新表统计信息：BigQuery优化器依赖表的统计数据生成计划，如果你的源表/目标表最近有大量数据写入、分区变更，可能导致统计信息过期。手动刷新试试：

  ANALYZE TABLE `你的项目ID.你的数据集ID.目标表/源表名`;
  

• 检查查询动态性：如果你的SQL是动态生成的（比如包含变量、动态表名），每次执行的查询文本略有差异，可能触发不同的执行计划。尽量把复杂查询逻辑封装成视图，固化执行逻辑。
• 用查询提示固定计划：如果某类执行计划更符合你的需求，可以用BigQuery的查询提示强制优化器选择特定策略，比如强制哈希连接：

  INSERT INTO `目标表`
  SELECT /*+ HASH_JOIN() */ * FROM `源表` WHERE 过滤条件;
  

• 提交官方支持工单：如果以上方法都没效果，建议通过Google Cloud Console提交BigQuery支持工单，附上作业ID和完整SQL语句，GCP技术团队可以帮你深挖执行计划变化的具体原因。

三、临时应急方案 #

如果需要在作业执行时实时获取插入行数，可以试试：

• 执行INSERT前先跑一次SELECT COUNT(*)统计待插入记录数（注意：如果源数据在两次查询之间有变更，会存在误差）
• 用BigQuery事务包裹INSERT和计数逻辑，确保数据一致性，但要注意事务的适用场景（需用标准SQL，表为普通/分区表，不是快照表）

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