我运行了一个查询，结果如下。
经过时间：12.1 秒
插槽时间消耗：14 小时 12 分钟
total_slot_ms：51147110（即 14 小时 12 分钟）
我们采用按需定价计划。所以最大插槽数为 2000。话虽如此，如果我在整个 12.1 秒的跨度内使用了 2000 个插槽，那么我最终的 total_slot_ms 应该为 24200000 （即 2000x12.1x1000强>）。但是，total_slot_ms 为 51147110。使用的平均插槽数为 51147110/121000 = 4225（远高于 2000）。有人可以向我解释一下我是如何使用超过 2000 个插槽的吗？
【问题讨论】：
标签： google-cloud-platform google-bigquery
增加 Bigquery 槽容量可显着提高整体查询性能，尽管槽量实际上是 Bigquery on-demand 定价计划中 Quotas 限制的主题，超过槽量限制不会向您收取额外费用：
BigQuery 槽在单个项目中的所有查询之间共享。 BigQuery 可能会超出此限制以加速您的查询。
要查看您正在使用的插槽数量，请参阅Monitoring BigQuery using Cloud Monitoring。
【讨论】：
BigQuery 按需支持有限突发。 https://cloud.google.com/bigquery/docs/release-notes#December_10_2019
【讨论】：
您可能想要检查查询的执行计划并了解每个阶段的等待、读取、写入活动的所有不同 slot_time_ms。由于这是按需时段，您可能会看到很多等待时间，这将加起来总时间。 除了burst之外，explain pan的每个阶段都会帮助你理解总时间不一定是实际slot消耗，而是等效slot消耗。
【讨论】：
在 Google 的课程中，有一个查询显示 13 个“经过的时间”秒和 50 分钟的“插槽时间消耗”的示例。他们说：
嘿，在我们所有的工作人员中，我们基本上并行完成了 50 分钟的大规模工作，50 分钟，以便您的查询可以在 13 秒内返回。对您来说最重要的是，您无需担心启动这些工作人员、在他们之间移动数据、确保他们在聚合之间共享所有结果。您所关心的只是编写 SQL，找到洞察力，然后以非常快的速度运行该查询。但是从你那里抽象出很多正在发生的分布式并行处理。
【讨论】：