瞭解運算單元

BigQuery 運算單元是 BigQuery 用來執行 SQL 查詢、Python 程式碼或其他工作類型的虛擬運算單元。執行查詢時，BigQuery 會自動判斷查詢使用的運算單元數量。使用的運算單元數量取決於處理的資料量、查詢的複雜程度，以及可用的運算單元數量。一般來說，可用的運算單元越多，就能執行更多並行查詢，複雜查詢的執行速度也會更快。您無法手動變更 BigQuery 用於執行查詢的運算單元數量。

隨選和以容量為準的計價方式

雖然所有查詢都會使用運算單元，但用量計費方式有兩種：以量計價模式或以運算資源為基礎的計價模式。

根據預設，系統會採用隨選模式計費。採用這種模式時，系統會根據每項查詢處理的資料量 (以 TiB 為單位) 向您收取資料處理費用。使用隨選模式的專案須遵守隨選價格的並行運算單元數量上限，並具備暫時性爆量功能。對於採用隨選模式的大多數使用者來說，這個上限已綽綽有餘。不過，視工作負載而定，存取更多運算單元可能會提升查詢效能。如要查看帳戶的運算單元用量，請參閱「監控健康狀態、資源使用率和工作」。

如果採用以運算資源為基礎的模式，則須依據查詢分配到的運算單元容量和時間長度付費。這個模式可讓您明確控管總時段容量。 您透過預留項目明確選擇要使用的運算單元數量。您可以將預留項目的運算單元數量指定為一律會分配的基準量，也可以指定為視需要分配的自動調度量。預留項目會自動調度運算單元，根據工作負載需求調整容量。BigQuery 會隨著工作負載變化分配運算單元。您可以根據使用預留項目的工作負載效能或重要性，設定預留項目的運算單元數量。

避免產生未預期的隨選費用

為避免未指派或新建立的專案預設採用隨選定價，請使用Google Cloud 資源階層，並遵循下列做法管理 BigQuery 預留項目：

• 在資料夾或組織層級指派：在資料夾或組織層級建立預留項目指派作業，而非逐一設定專案。這樣可確保該階層中的所有現有和未來專案，都會自動沿用預留項目並使用預留項目的運算單元容量。
• 考量預設行為：如果沒有明確或繼承的指派項目，BigQuery 會自動套用隨選定價模式。
• 例外狀況的覆寫：如果特定專案必須使用隨選價格，您可以明確將這些專案指派給「無」預留項目，藉此覆寫繼承的指派項目。

如要進一步瞭解指派作業優先順序，請參閱「預留項目指派作業」。

使用時段執行查詢

BigQuery 執行查詢工作時，會將 SQL 陳述式轉換為執行計畫，其中包含一系列查詢階段。階段則是由一組執行步驟組成。BigQuery 使用分散式平行架構執行查詢。階段會模擬可平行執行的工作單元。資料會使用分散式重組架構在階段之間傳遞，詳情請參閱這篇 Google Cloud 網誌文章。

BigQuery 查詢執行作業是動態的。查詢處理期間可以修改查詢計畫。新增階段後，工作分配可針對資料分配進行最佳化。此外，查詢的執行容量可能會隨著其他查詢開始或完成，或是自動調度程式將配額新增至預留項目而變更。

BigQuery 可以並行執行多個階段，也可以使用推測執行來加快查詢速度，並動態重新劃分階段，以達到最佳平行處理。

運算單元資源經濟

如果查詢要求的運算單元數量超過可用數量，BigQuery 會將個別工作單位排入佇列，並等待有可用的運算單元釋出。當查詢作業取得進展及運算單元釋出時，這些佇列中的作業單元會以動態方式開始執行。

BigQuery 可為查詢的特定階段要求任意數量的運算單元。要求的運算單元數量與您購買的容量無關，而是 BigQuery 為該階段選擇的最佳平行處理因子的指標。工作單元會排入佇列，並在運算單元可用時執行。

當查詢需求超過可用運算單元時，您無須為額外的運算單元支付費用，系統也不會按照額外的隨選費率向您收費。個別工作單位會排入佇列。

例如，假設使用者要求系統 將文字從英文翻譯成法文

1. 某個查詢階段要求 2,000 個運算單元，但只有 1,000 個可用。
2. BigQuery 會耗用所有 1,000 個運算單元，並將其他 1,000 個運算單元排入佇列。
3. 之後，如果有 100 個運算單元完成工作，它們就會以動態的方式，從佇列中的 1,000 個工作單元裡挑出 100 個工作單元。佇列中還有 900 個工作單位。
4. 之後，如果有 500 個運算單元完成工作，它們就會以動態的方式，從佇列中的 900 個工作單元裡挑出 500 個工作單元。仍有 400 個工作單元排隊等候處理。

如果需求量超過可用量，BigQuery 運算單元會排入佇列

如果工作負載需要的運算單元超過預留項目可用的數量，工作會等待運算單元釋出，因此工作執行時間可能會增加。這就是所謂的「時段爭用」。如果工作負載需求遠大於預留項目可用的運算單元，運算單元爭用情形可能會增加。

容量優先順序

如果特定區域的運算單元資源需求量過高，BigQuery 會優先處理容量，藉此管理爭用情形。這項優先順序可確保使用較高層級容量模式的客戶受到的影響較小。系統會依下列順序決定容量優先順序：

1. Enterprise Plus 和 Enterprise 版本的基準和承諾使用容量。
2. Enterprise Plus 自動調度資源容量。
3. Enterprise 版自動調度資源。
4. 標準版和隨選容量。

如果某個區域發生資源爭用情形，Standard 版本和隨選運算能力要求較可能發生存取延遲，因為系統會優先將資源分配給較高階的版本。

BigQuery 中的公平排程

BigQuery 會使用稱為「公平排程」的演算法，在單一預留項目中分配運算單元容量。

BigQuery 排程器會強制執行以下規則：在預留項目中，執行查詢的專案會平均分配運算單元，然後在特定專案的工作中，也會平均分配運算單元。排程器最終會提供公平性。在短期內，某些工作可能會獲得不成比例的時段，但排程器最終會修正這個問題。排程器的目標是找出平衡點，避免過於積極地終止執行中的工作 (導致浪費時段時間)，以及過於寬鬆 (導致執行時間較長的工作獲得不成比例的時段時間)。

公平排程可確保每項查詢隨時都能存取所有可用運算單元，並在各項查詢的容量需求變更時，動態自動重新分配有效查詢的容量。在下列情況下，查詢會完成，並提交新查詢以執行：

• 每當您提交新的查詢時，系統會自動把運算能力重新分配給所有執行中的查詢。隨著每個查詢可用的運算能力越來越多，個別的工作單元就能順利地、暫停、繼續執行，以及加入佇列。
• 每當有查詢執行完畢時，系統會立刻自動將該查詢占用的運算能力提供給所有其他的查詢使用。
• 每當查詢的動態 DAG 發生變化，導致查詢的容量需求改變時，BigQuery 就會自動重新評估這項查詢和所有其他查詢的可用容量，並視需要重新分配及暫停運算單元。

BigQuery 中的公平排程

視複雜度和大小而定，查詢可能不需要所有有權使用的運算單元，也可能需要更多運算單元。BigQuery 會動態確保在公平排程的情況下，所有時段都能充分運用所有配額。

如果重要工作持續需要比排程器提供的運算單元更多，請考慮建立額外的預留項目，並指派所需數量的運算單元給該工作。

以公平調度為例，假設您有下列預訂設定：

• 預留項目 A，有 1,000 個基準運算單元，不自動調度資源
• 指派給預留項目的專案 A 和專案 B

情境 1：您在專案 A 中執行查詢 A (一個並行查詢)，需要大量運算單元，並在專案 B 中執行 20 個並行查詢。雖然共有 21 個查詢使用預留項目 A，但運算單元分配情形如下：

• 專案 A 獲得 500 個運算單元，查詢 A 則以 500 個運算單元執行。
• 專案 B 獲得 500 個運算單元，由 20 項查詢共用。

情境 2：在專案 A 中，您執行查詢 A (一個並行查詢)，需要 100 個運算單元才能執行；在專案 B 中，您執行 20 個並行查詢。由於查詢 A 不需要 50% 的預留項目，因此運算單元分配如下：

• 專案 A 獲得 100 個運算單元，查詢 A 則以 100 個運算單元執行。
• 專案 B 獲得 900 個運算單元，由 20 項查詢共用。

相反地，請考慮下列預留項目設定：

• 預留項目 B，有 1,000 個基準運算單元，但不會自動調度資源。
• 10 項專案，全部指派給預留項目 B。

假設這 10 項專案執行的查詢有足夠的運算單元需求，則每項專案都會收到總預留運算單元的 1/10 (或 100 個運算單元)，無論每項專案執行的查詢數量為何。

配額與限制

運算單元配額和限制可為 BigQuery 提供安全防護。不同定價模式使用的配額類型不同，如下所示：

• 隨選定價模式：您必須遵守隨選定價模式的並行運算單元數量上限，並具備暫時性爆發能力。視工作負載而定，存取更多時段可提升查詢效能。

• 以容量為準的價格模式：預留項目配額和限制會定義您在某個位置的所有預留項目中，可分配的運算單元數量上限。如果您使用自動調整資源配置，預留項目大小上限總和不得超過此限制。系統只會針對預留項目和承諾用量收費，不會針對配額收費。如要瞭解如何提高運算單元配額，請參閱「申請提高配額」。

請注意，已分配的時段 (會影響配額和帳單) 與已使用的時段 (代表運算資源的實際用量) 不同。如要詳細比較兩者，請參閱「瞭解運算單元指標」。

如要查看使用的運算單元數量，請參閱「BigQuery 監控」。

閒置的運算單元

閒置運算單元的概念僅適用於依運算資源計價模式，不適用於自動調度資源的運算單元。在下列兩種情況下，系統會將運算單元視為「閒置」：

• 承諾使用合約中的運算單元，但未分配給任何預留項目基準。
• 已分配給預留項目基準，但預留項目中的工作並未積極使用的運算單元。

為充分發揮購買運算資源的價值和效率，BigQuery 會自動共用這些閒置運算單元。根據預設，在任何預留項目中執行的查詢，都可以使用相同管理專案中其他預留項目的閒置運算單元。

當「擁有」這些運算單元的預留項目需要使用時，BigQuery 會立即收回。歸還借用運算單元的作業會在幾毫秒內順利完成，確保擁有預留項目的工作負載不受影響。在這段短暫的交接期間，您可能會在監控圖表中發現，所有預留項目的總運算單元用量短暫超過總容量。這是運算單元搶占和分配程序的正常現象，您不必為這項暫時的額外用量付費。

舉例來說，假設您有下列預訂設定：

• project_a 指派給 reservation_a，後者有 500 個基準運算單元，且未啟用自動調整資源配置功能。
• project_b 指派給 reservation_b，後者有 100 個基準運算單元，且未啟用自動調度功能。
• 這兩個預留項目位於相同的區域和管理專案，且沒有其他專案指派給這些預留項目。

您在 project_b 中執行 query_b。如果 project_a 中沒有執行任何查詢，則 query_b 可以存取 reservation_a 的 500 個閒置運算單元。query_b 仍在執行時，最多可能會使用 600 個運算單元：100 個基本運算單元加上 500 個閒置運算單元。

query_b 執行期間，假設您在可使用 500 個運算單元的 project_a 中執行 query_a。

• 由於您為 project_a 預留了 500 個基準運算單元，query_a 會立即啟動並分配到 500 個運算單元。
• 分配給 query_b 的運算單元數量會迅速減少至 100 個基準運算單元。
• 在 project_b 中執行的其他查詢會共用這 100 個運算單元。如果後續查詢沒有足夠的運算單元可啟動，就會排入佇列，直到執行中的查詢完成且運算單元可用為止。

在這個例子中，如果 project_b 分配給沒有基準運算單元或自動調度資源的預留項目，則 query_a 開始執行後，query_b 就沒有運算單元。BigQuery 會暫停query_b，直到有閒置運算單元可用或查詢逾時為止。project_b 中的其他查詢會排入佇列，直到有閒置運算單元為止。

控管及限制閒置運算單元共用

如要防止特定預留項目借用其他預留項目的閒置運算單元，請將其 ignore_idle_slots 屬性設為 true。請注意，這項設定只會控管借用，不會控管出借。如果預留項目的 ignore_idle_slots 設為 true，就無法再借用運算能力，但仍可將自己的閒置運算單元借給其他需要的預留項目。只要 ignore_idle_slots 為 false，預留項目的運算單元數量可以是 0，且仍可存取未使用的運算單元。

除了 ignore_idle_slots 之外，您還可以使用下列機制，管理及控管各工作負載的閒置運算單元共用設定：

• 預留項目公平性：將閒置運算單元平均分配給預留項目，而非個別專案，避免多專案工作負載壟斷閒置運算單元集區。如要啟用這項設定，請參閱「啟用預留項目公平性」。
• 可預測的預留項目：設定使用容量 (包括閒置運算單元) 時的最大容量界限，確保資源擴充可預測，不會突然爆量。如需設定步驟，請參閱「建立可預測的預留項目」。
• 預留項目群組：將相關預留項目歸為一組，限制群組的運算單元總用量，並優先在群組內共用閒置運算單元，再與組織共用。如要設定群組，請參閱「建立預留項目群組」。

閒置時段共用功能有兩項主要限制：

• 不同版本的預留項目之間無法共用閒置運算單元。
• ML_EXTERNAL 類型的指派作業是例外狀況，因為 BigQuery ML 外部模型建立工作使用的運算單元無法先占。如果預留項目同時有 ML_EXTERNAL 和 QUERY 指派類型，只有在 ML_EXTERNAL 工作未佔用運算單元時，其他查詢工作才能使用這些運算單元。此外，這些工作無法使用其他預留項目的閒置運算單元。

以預留項目為基礎的公平性機制

注意： 2026 年 10 月 10 日後建立的管理專案，預設會啟用預留項目公平性。如果是 2026 年 10 月 10 日前建立的專案，您必須先啟用以預留項目為準的公平性，才能建立可預測的預留項目。

採用以預留項目為準的公平性機制後，BigQuery 會優先處理同一管理員專案內所有預留項目，並平均分配閒置運算單元，無論各預留項目中執行工作的專案數量為何。每個預留項目都會從閒置運算單元集區中，獲得相近的可用容量配額，然後在專案中公平分配運算單元。這項功能僅適用於 Enterprise 或 Enterprise Plus 版本。

下圖顯示未啟用預留公平性時，閒置運算單元的分配方式：

在這張圖表中，閒置運算單元會平均分配給各項專案。

如果未啟用以預留項目為基礎的公平性機制，可用的閒置運算單元會平均分配給預留項目中的專案。

下圖顯示啟用以預訂為準的公平性後，閒置時段的分配方式：

在這張圖表中，閒置運算單元會平均分配給預留項目，而非專案。

啟用以預留項目為基礎的公平性機制後，可用的閒置運算單元會平均分配給各個預留項目。

啟用以預訂為準的公平性後，請查看資源用量，管理可用的時段和查詢效能。

如果正式環境工作負載有嚴格的時間要求，請避免僅依賴閒置運算單元，這類工作必須使用基準或自動調度資源的運算單元。建議將閒置運算單元用於優先順序較低的工作，因為運算單元隨時可能遭到占用。

運算單元自動調度

下一節將討論自動調整資源配置運算單元，以及這項功能如何與預留項目搭配運作。

使用自動調度資源預留項目

建立自動調度資源預留項目之前，您不需要購買運算單元承諾使用合約。運算單元承諾使用合約可為持續使用的運算單元提供折扣費率，但自動調度資源預留項目不一定要使用。如要建立自動調度資源預留項目，請為預留項目指派運算單元數量上限 (預留項目大小上限)。如要找出自動調度資源運算單元數量上限，請將預留項目大小上限，減去指派給預留項目的任何選用基準運算單元。

建立自動調度資源預留項目時，請注意下列事項：

• BigQuery 會近乎即時地調整預留項目，直到達到執行工作所需的運算單元數量，或是達到預留項目可用的運算單元數量上限為止。運算單元一律會自動調度資源，並以 50 的倍數為單位。
• 擴充依據為實際用量，並會進位至最接近的 50 個運算單元增量。
• 自動調度運算單元會以相關聯版本的容量運算價格計費。系統會根據擴充的運算單元數量計費，而非使用的運算單元數量。即使導致 BigQuery 擴充資源的工作失敗，仍須支付這筆費用。因此，請勿使用工作資訊結構定義來比對帳單。請改為參閱「使用資訊結構定義監控自動調度資源」。
• 運算單元數量一律會以 50 的倍數調整，但單一步驟的調整幅度可能超過 50 個運算單元。舉例來說，如果工作負載需要額外 450 個運算單元，BigQuery 可以嘗試一次擴充 450 個運算單元，以滿足容量需求。
• 當與預留項目相關聯的工作不再需要運算資源時，BigQuery 就會縮減資源。預設情況下，容量的計費單位為秒，且有 1 分鐘的最低使用時間。您可以在預留項目層級選擇加入 BigQuery 流暢擴充功能，按秒計費，且沒有最短時間限制。

注意： 變更預留項目的運算單元數量上限後，可能需要幾秒鐘才會生效。

任何自動調度的容量都會保留至少 60 秒。這 60 秒的期間稱為縮減視窗。只要容量達到新的高峰，縮減時間範圍就會重設，並將整個容量層級視為新的授權。不過，如果自上次增加容量以來已超過 60 秒，且需求量較低，系統會減少容量，但不會重設縮減時間範圍，因此可連續減少容量，不會造成延遲。

舉例來說，如果初始工作負載容量擴充至 100 個運算單元，尖峰用量會保留至少 60 秒。如果在縮減期間，工作負載擴充至 200 個運算單元的新高峰，則會開始新的 60 秒縮減期間。如果在這段縮減時間內沒有新的尖峰，工作負載就會在 60 秒後開始縮減。

請參考以下詳細範例：在 12:00:00，初始運算資源擴充至 100 個運算單元，用量持續一秒。這個尖峰值會從 12:00:00 開始維持至少 60 秒。60 秒後 (12:01:01)，如果新用量為 50 個運算單元，BigQuery 會縮減至 50 個運算單元。如果 12:01:02 的新用量為 0 個運算單元，BigQuery 會立即再次縮減至 0 個運算單元。縮減時間範圍結束後，BigQuery 可以連續縮減多次，不需新的縮減時間範圍。

BigQuery 流暢擴充

BigQuery 流暢擴充功能會移除標準自動調度資源功能所需的一分鐘最短時間長度，並每秒調整運算單元容量。這項功能不會改變 50 個運算單元的擴充級距。

為快速因應預留項目需求，BigQuery 流暢擴充功能會以短時間增量為單位，在預留項目之間分配閒置運算單元，因此預留項目獲得的閒置運算單元數量，會略多於或少於預留項目應得的公平分配量。

如要瞭解如何啟用這項功能，請參閱「更新預訂」。

如果預留項目使用代管災難復原功能，則主要和次要區域都必須啟用 BigQuery 流暢擴充功能，才能確保容錯移轉後按秒計費。

如要瞭解如何使用自動調整功能，請參閱「管理工作負載預留項目」。

使用預留項目搭配基準和自動調度資源運算單元

除了指定預留項目大小上限外，您也可以視需要指定每個預留項目的基準運算單元數量。「基準數量」是指一律會分配給預留項目的運算單元最小數量，而且必定會產生這個數量的運算單元費用。只有在所有基準運算單元 (和閒置運算單元，如適用) 都用完後，系統才會新增自動調度資源運算單元。您可以將某個預留項目中的閒置基準運算單元，分享給其他需要運算能力的預留項目。

每隔幾分鐘，您就可以增加預留項目的基準運算單元數量。如要減少基準運算單元，且最近曾變更基準運算單元容量，而基準運算單元超過承諾使用運算單元，則每小時只能變更一次。否則，您可以每隔幾分鐘減少基準運算單元。

基準和自動調度資源的運算單元會根據您最近的工作負載提供容量。如果您預期會有大量工作負載，且與最近的工作負載有很大差異，建議您在事件發生前提高基準容量，而不是依賴自動調度資源運算單元來涵蓋工作負載容量。如果提高基準容量時發生問題，請等待 15 分鐘後再重試。

如果預留項目沒有基準運算單元，或未設定從其他預留項目借用閒置運算單元，BigQuery 就會嘗試擴充。否則，基準運算單元必須完全用盡，才會擴充。

預留項目會依據下列順序使用及新增運算單元：

1. 基準運算單元。
2. 閒置運算單元共用功能 (如果已啟用)。預留項目只能與其他預留項目共用閒置的基準或承諾運算單元，且這些預留項目必須以相同版本和區域建立。
3. 自動調度運算單元。

在下列範例中，廣告空間會從指定基準金額開始調整。「etl」和「dashboard」預留項目的基準大小分別為 700 和 300 個運算單元。

在本例中，etl 預留項目可擴充至 1, 300 個運算單元 (700 個基準運算單元加上 600 個自動調度運算單元)。如果 dashboard 預留項目未使用中，etl 預留項目就能使用 dashboard 預留項目的 300 個運算單元 (前提是該預留項目沒有執行任何工作)，因此最多可使用 1,600 個運算單元。

dashboard 預留項目可擴充至 1,100 個運算單元 (300 個基準運算單元加上 800 個自動調度資源運算單元)。如果 etl 預留項目完全閒置，dashboard 預留項目最多可擴充至 1, 800 個運算單元 (300 個基準運算單元加上 800 個自動調度資源運算單元，再加上 etl 預留項目中的 700 個閒置運算單元)。

如果 etl 預留項目需要超過 700 個基準運算單元 (一律可用)，則會嘗試依序使用下列方法新增運算單元：

1. 700 個基準運算單元。
2. 與 dashboard 預留項目中的 300 個基準運算單元共用閒置運算單元。預留項目只會與使用相同版本建立的其他預留項目，共用閒置的基準運算單元。
3. 擴充 600 個運算單元，達到預留項目大小上限。

使用運算單元承諾

以下範例說明如何使用容量承諾自動調度資源運算單元。

與預留項目基準一樣，運算單元承諾使用合約可讓您分配固定數量的運算單元，供所有預留項目使用。與基準運算單元不同，承諾使用合約在合約期間內無法縮減。運算單元承諾使用合約為選用項目，但如果長期需要基準運算單元，可藉此節省費用。運算單元承諾使用合約用於支付預留項目的基準運算單元費用。任何未使用的運算單元容量，都會做為閒置運算單元，與其他預留項目共用。運算單元承諾使用合約不適用於自動調度資源運算單元。為確保您能以折扣費率使用承諾運算單元，請確認承諾運算單元數量足以涵蓋基準運算單元。

在這個範例中，系統會按照預先定義的費率，向您收取容量承諾使用方案運算單元的費用。自動調度資源功能啟用且預留項目處於擴充狀態後，系統會根據自動調度資源運算單元數量，按照自動調度資源費率向您收費。如果是自動調度資源費率，系統會根據調度的運算單元數量計費，而非使用的運算單元數量。

以下範例顯示基準運算單元數量超過承諾使用運算單元數量時的預留項目。

在這個範例中，兩個預留項目之間共有 1000 個基準運算單元，其中 500 個來自 etl 預留項目，另外 500 個來自 dashboard 預留項目。不過，承諾使用合約僅涵蓋 800 個運算單元。在此情況下，系統會按照即付即用 (PAYG) 費率，收取超額的配額費用。

可用運算單元數量上限

如要計算預留項目可使用的運算單元數量上限，請將基準運算單元、自動調度資源運算單元數量上限，以及以相同版本建立且不屬於基準運算單元的任何承諾使用運算單元加總。以下範例的設定如下：

• 承諾每年使用 1,000 個運算單元。這些運算單元會指派為 etl 預留項目和 dashboard 預留項目的基準運算單元。
• 指派給 etl 預留項目的基準運算單元數量為 700 個。
• 指派給 dashboard 預留項目的 300 個基準運算單元。
• etl 預留項目的自動調度運算單元為 600 個。
• dashboard 預留項目的自動調度運算單元為 800。

對於 etl 預留項目，運算單元數量上限等於 etl 基準運算單元 (700) 加上 dashboard 基準運算單元 (300，如果所有運算單元都閒置)，再加上自動調度資源運算單元數量上限 (600)。因此，在本例中，etl 預留項目最多可使用 1,600 個運算單元。這個數字超過容量承諾中的數字。

在以下範例中，年約承諾使用量超過指派的基準運算單元。

在這個範例中，我們有：

• 承諾每年使用 1,600 個運算單元。
• 預留項目大小上限為 1500 (包括 500 個自動調度資源運算單元)。
• 1,000 個基準運算單元指派給 etl 預留項目。

預留項目可用的運算單元數量上限，等於基準運算單元數量 (1000) 加上未專用於基準運算單元的任何承諾使用閒置運算單元 (1600 個年度運算單元 - 1000 個基準運算單元 = 600) 加上自動調整資源配置運算單元數量 (500)。因此，這個預留項目的運算單元數量上限為 2100。自動調度資源的運算單元是超出承諾使用量的額外運算單元。

有時 BigQuery 可能會使用可用的 BigQuery 系統容量，以高於運算單元限制的速度處理查詢。在這種情況下，BigQuery 會延遲傳回最終查詢結果，直到標準運算單元容量足以涵蓋用量暴增，確保您不會支付超過上限的費用，同時仍會計算使用的總運算量。

自動調度資源最佳做法

• 初次使用自動配置器時，請根據過去和預期的效能，將自動調度資源運算單元數量設為有意義的值。預訂建立完成後，請主動監控失敗率、效能和帳單，並視需要調整自動調度資源的配額數量。

• 自動配置器至少要 1 分鐘後才會縮減資源，因此請務必設定自動調度運算單元數量上限，在效能和成本之間取得平衡。如果自動調度資源運算單元數量上限過高，且工作可在幾秒內使用所有運算單元完成，您仍須支付整分鐘的運算單元費用。如果將最大運算單元數調降為目前的一半，預留項目就會縮減，工作在這段時間內可使用更多 slot_seconds，減少浪費。如需判斷運算單元需求的協助，請參閱「監控工作效能」。如要瞭解判斷運算單元需求的替代方法，請參閱「查看版本運算單元建議」。

• 運算單元用量有時可能會超過基準運算單元加上調度運算單元的總和。如果運算單元用量超過基準運算單元加上擴充運算單元，您就不必支付相關費用。

• 自動配置器最適合用於大量長時間執行的工作負載，例如有多個並行查詢的工作負載。請避免一次傳送一項查詢，因為每項查詢都會擴充預留項目，且預留項目會維持擴充狀態至少 1 分鐘。如果您持續傳送查詢，導致工作負載不間斷，設定基準並購買承諾使用合約，就能以折扣價格獲得不間斷的運算能力。

• BigQuery 自動調度資源功能受限於可用容量。BigQuery 會根據過往用量，盡量滿足客戶的容量需求。您可以設定選用的運算單元基準，以便立即使用運算單元。無論是否使用基準，都必須付費。為確保有足夠的容量因應大型、非自然的需求 (例如高流量的節慶)，請提前幾週與 BigQuery 團隊聯絡。

• 基準運算單元一律會產生費用。如果運算資源承諾使用合約到期，您可能需要手動調整預留項目中的基準運算單元數量，以免產生不必要的費用。舉例來說，假設您有 1 年期承諾使用合約，其中包含 100 個運算單元，以及 100 個基準運算單元的預留項目。合約到期，且未設定續約方案。承諾期結束後，您需要以即付即用費率支付 100 個基準運算單元的費用。

觀測能力

如要瞭解如何透過自動調度資源功能監控運算單元用量和工作效能，請參閱「監控自動調度資源」。