BigQuery MERGE任务突发性能劣化：数据量减少但Slot耗时激增求助

我在asia-southeast1区域使用BigQuery按需付费模式。自2026-06-04起，部分定时MERGE任务开始随机超时。此前相同工作负载均能稳定完成，现在部分运行会触发10分钟的应用超时阈值。手动重新运行相同SQL有时很快完成，有时则卡顿严重。

查询模式 #

该查询使用JavaScript UDF提取嵌套数组后合并至子表，具体结构如下：

MERGE INTO `project.dataset.target_child_table` AS target
USING (
  WITH docs AS (
    SELECT *
    FROM `project.dataset_changelog.source_table`
    WHERE publish_time BETWEEN TIMESTAMP('...') AND TIMESTAMP('...')
  ),
  raw_table AS (
    SELECT JSON_QUERY_ARRAY(
      JSON_EXTRACT(
        `project.dataset.transformDoc`(
          data, id, db_name, publish_time, deleted, 'documentType'
        ),
        '$.nestedArray'
      )
    ) AS nestedArray
    FROM docs
  )
  SELECT ...
  FROM raw_table
  CROSS JOIN UNNEST(nestedArray) AS child
) AS source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT ...;

Slot效率分析 #

我通过INFORMATION_SCHEMA.JOBS_BY_PROJECT中的任务元数据计算Slot效率，公式如下：

slot_minutes_per_gib =
  (SUM(total_slot_ms) / 1000 / 60)
  / (SUM(total_bytes_processed) / POW(1024, 3))

匿名化后的统计结果：

可见6月4日处理的数据量更少，但每GiB数据的Slot使用量大幅上升：

• child_table_a: 2.49 → 10.60 slot-min/GiB
• child_table_b: 1.35 → 24.95 slot-min/GiB

源数据时间窗口始终≤30分钟，且DML行数增幅不足以解释此现象。

小型非子表MERGE的额外测试 #

为验证问题是否仅由大型子数组表导致，我对比了一个规模小得多的非子表MERGE任务——该查询未使用CROSS JOIN UNNEST/子数组提取，仅将转换后的文档合并为目标表的单行格式。

匿名化测试结果：

即使是小型任务也出现异常：

• 任务数量相近
• 源数据窗口大小相近
• 处理的数据量仍很小
• 但p95耗时从46秒跃升至619秒

这说明问题并非仅由大型目标表、子数组膨胀或更大的源窗口导致，更可能与BigQuery MERGE执行行为变更、JavaScript UDF运行时、DML/写入路径竞争或按需执行差异有关。

疑问 #

近期有没有人在asia-southeast1区域的BigQuery按需付费模式下遇到类似情况？可能的原因是什么？

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