在过去一周左右，我们以交互模式提交给BigQuery的SQL的一个子集（每天数千个中的单个数字）开始花费数小时而不是几秒钟。超时作业的SQL出现在非常具体的案例中。我能够从BigQuery控制台重现这两个作业的行为：
工作调用（在5秒内运行）：
Job ID bluecore-qa:US.bquijob_4e0e4662_1639a278fcf
Creation Time May 25, 2018, 9:54:34 PM
Start Time May 25, 2018, 9:54:34 PM
End Time May 25, 2018, 9:54:39 PM
Bytes Processed 176 MB
Bytes Billed 177 MB
Slot Time (ms) 271 K
完全相同的SQL（不到一分钟后运行）在6小时后超时：
Job ID bluecore-qa:US.bquijob_57c799e2_1639a2852fa
Creation Time May 25, 2018, 9:55:24 PM
Start Time May 25, 2018, 9:55:24 PM
Query Priority Interactive
Job Type State Start Time Duration User Email Bytes Processed Bytes Billed Billing Tier Labels
---------- --------- ----------------- ---------- --------------------- ----------------- -------------- -------------- --------
query FAILURE 25 May 21:55:24 5:59:45 xxxxx
Error encountered during job execution:
Request timed out. Please try again.
请注意，SQL确实使用了'IGNORE CASE'，这在过去对我们来说是个问题（但通常会导致'内部错误'）。
有没有办法获得有关作业的更多信息，以查看第二个作业是否被推回到BigQuery调度队列中？ （根据BigQuery StackDriver的统计数据，我们在2000年的项目限制范围内保持不变）。
答案 0 :(得分：0)
在BigQuery中，作业从未推回到BigQuery调度队列（即使在流媒体和交互模式下）。
您可以使用Audit logs获取有关超时的更多详细信息。审计日志记录是目前唯一可用于Stackdriver的方法。
答案 1 :(得分：0)
这是Google BigQuery方面的问题。他们正在修复此问题，并且一旦发布就会更新https://issuetracker.google.com/issues/80407917。