配額與限制

這份文件列出 BigQuery 適用的配額和系統限制。

  • 「配額」有預設值，但通常可以申請調整。
  • 「系統限制」是固定值，無法變更。

Google Cloud 使用配額來確保公平性，並減少資源使用量和可用性出現劇烈波動的情況。配額會限制 Google Cloud 專案可使用的Google Cloud 資源數量，且適用多種資源類型，包括軟硬體和網路元件。舉例來說，配額可能會限制能向特定服務發出的 API 呼叫次數、專案可同時使用的負載平衡器數量，或是可建立的專案數量。配額機制可防止服務過載，保障Google Cloud 使用者社群的權益，同時也有助於您管理自己的 Google Cloud 資源。

Cloud Quotas 系統具備以下功能：

如果嘗試使用的資源量超過配額限制，系統通常會阻擋該資源的存取活動，您所執行的工作就會失敗。

配額的計算通常是以 Google Cloud 專案為基準。在某個專案中使用資源，不會影響另一個專案的可用配額。在同一個 Google Cloud 專案內，所有應用程式和 IP 位址會共用配額。

詳情請參閱「Cloud Quotas 總覽」。

BigQuery 資源也有「系統限制」，而且無法變更。

部分錯誤訊息會指出可提高的配額或限制，其他錯誤訊息則會指出無法提高的配額或限制。達到硬性限制表示您需要為工作負載實作暫時或永久的替代方案，或是最佳做法。即使配額或限制可以增加，也建議您這麼做。如要進一步瞭解這兩種錯誤，請參閱「排解配額和限制錯誤」。

運算單元配額用量計算

如果專案採用以運算量為準的計價模式 (包括 BigQuery 版本)，「運算單元總數」配額的「已用」欄會顯示特定區域的已分配運算量總數。這個值包含預訂中定義的所有基準運算單元，以及任何有效的容量承諾。由於基準時段是專用的可用資源，即使閒置，配額系統也會將其視為「已使用」。如要進一步瞭解這項功能與資源監控的差異，請參閱「瞭解時段指標」。

根據預設，BigQuery 配額和限制會以專案為單位套用。如果配額和限制適用於不同基準，系統會標示出來；例如，每個資料表的欄數上限，或是每位使用者可同時發出的 API 要求數上限。具體規定會因資源供應狀況、使用者個人資料、服務使用情形和其他因素而異，並隨時可能在不知會的情況下變更。

配額重設

在一天當中，系統會定時為您補充每日配額，以便達到控管頻率限制行為的目標。另外，系統也會間歇性重新整理，以免在配額耗盡時發生服務長時間中斷的狀況。一般來說，系統在幾分鐘內即可提供更多配額，並非一天僅全面補充一次。

申請提高配額

如要調整大部分配額，請使用 Google Cloud 控制台。詳情請參閱「要求調整配額」。

如需在 Google Cloud 控制台中申請提高配額的逐步指南，請按一下「Guide me」(逐步引導)：

逐步引導

設下配額用量上限

如要瞭解如何建立配額覆寫，限制特定資源的使用量，請參閱「建立配額覆寫」。

所需權限

如要在Google Cloud 控制台中查看及更新 BigQuery 配額，您必須具備與任何配額相同的權限。 Google Cloud詳情請參閱「Google Cloud 配額權限」。

疑難排解

如要瞭解如何排解配額和限制相關錯誤，請參閱「排解 BigQuery 配額錯誤」。

工作

無論是使用 Google Cloud 控制台、bq 指令列工具，還是以程式輔助方式使用 REST API 或用戶端程式庫，BigQuery 代表您執行的工作都會受到配額和限制規範。

待處理工作

BigQuery 中待處理的工作有以下限制：

限制 預設 附註
待處理工作數量上限 每個專案和區域 50,000 項工作 可處於待處理狀態的並行工作數量。此上限無法提高。詳情請參閱「排解 BigQuery 配額錯誤」。

查詢工作

下列配額適用於透過執行互動式查詢、排定查詢，以及使用 jobs.query 和查詢類型 jobs.insert API 方法提交工作，自動建立的查詢工作。

如需疑難排解資訊，請參閱 BigQuery 的疑難排解頁面。

配額 預設 附註
每日查詢用量 200 Tebibytes (TiB) 這項配額僅適用於以量計價的查詢定價模式。
您的專案每天最多可執行 200 TiB 的查詢。你隨時可以變更這項限制。如要進一步瞭解費用控管，請參閱「建立自訂查詢配額」。
在 Google Cloud 控制台中查看配額
每位使用者每日的查詢用量 無限制 這項配額僅適用於以量計價的查詢定價模式。
根據預設，使用者每天可執行的查詢量沒有限制。你隨時可以設定限制。無論每位使用者的限制為何，專案中所有使用者的總用量絕不會超過每日查詢用量限制。如要進一步瞭解費用控管，請參閱「建立自訂查詢配額」。
在 Google Cloud 控制台中查看配額
GoogleSQL 聯合查詢跨區域位元組數 (每日) 1 TB 如果 BigQuery 查詢處理位置和 Cloud SQL 執行個體位置不同，則查詢為跨區域查詢。您的專案每天最多可執行 1 TB 的跨區域查詢。請參閱「Cloud SQL 聯合查詢」。
在 Google Cloud 控制台中查看配額
BigQuery Omni 每日轉移位元組數 1 TB 您每天最多可從 Amazon S3 值區或 Azure Blob 儲存體移轉 1 TB 的資料。
在 Google Cloud 控制台中查看配額
每項 BigQuery Omni 工作轉移的位元組數 60 GB 在 BigQuery Omni 區域中執行 CREATE TABLE AS SELECT (CTAS) 或 INSERT INTO SELECT 陳述式，在跨雲端移轉期間篩選資料時，每個工作的最大移轉大小為 60 GB。這項限制也適用於 BigQuery Omni 聯結，這項功能會在背景執行 Omni CTAS 查詢，將資料移轉至 BigQuery 區域的暫時資料表。如要申請提高上限，請與支援團隊聯絡。 詳情請參閱「BigQuery Omni join 費用」。
每個區域配對每天透過全域查詢傳輸的位元組數 180 TB 使用全域查詢，您可以在每對區域之間每天轉移最多 180 TB 的資料。 如要申請提高配額，請與支援團隊聯絡。
每個專案的全球查詢複製工作 10,000 執行全域查詢時，每個專案最多可執行 10,000 個複製作業，在區域之間複製資料。一項全域查詢可能會觸發多項複製工作。 如要申請提高配額，請與支援團隊聯絡。
全域查詢中單一複製作業傳輸的位元組數 100 GB 根據預設，屬於全域查詢的單一複製工作最多可傳輸 100 GB。如要申請提高上限，請與支援團隊聯絡。
全域專案層級選項更新 5

執行會變更全域設定選項的 DDL 陳述式時，每 10 秒最多可執行五個陳述式。這項限制適用於下列 DDL 陳述式：

下列限制適用於透過執行互動式查詢、排定查詢，以及使用 jobs.query 和查詢類型 jobs.insert API 方法提交工作，自動建立的查詢工作：

限制 預設 附註
佇列中的互動式查詢數量上限 1,000 次查詢 您的專案最多可將 1,000 個互動式查詢加入佇列。 如果互動式查詢超出這個上限，系統會傳回配額錯誤。如要排解這些錯誤，請參閱「避免大量互動式查詢的限制」。
已達批次查詢佇列數量上限 20,000 項查詢 專案最多可將 20,000 個批次查詢加入佇列。如果其他批次查詢超出這個上限，系統會傳回配額錯誤。
針對 Bigtable 外部資料來源執行的並行互動式查詢數量上限 16 項查詢 您的專案最多可對 Bigtable 外部資料來源執行 16 項並行查詢。
包含遠端函式的並行查詢數量上限 10 項查詢 每個專案最多可使用 遠端函式執行十項並行查詢。
並行多重陳述式查詢數量上限 1,000 次多陳述式查詢 您的專案最多可執行 1,000 個並行多陳述式查詢。如要瞭解與多重陳述式查詢相關的其他配額和限制，請參閱「 多重陳述式查詢」。
包含 UDF 的並行舊版 SQL 查詢數量上限 6 項查詢 您的專案最多可同時執行六項含有使用者定義函式 (UDF) 的舊版 SQL 查詢。這項限制包括互動式和批次查詢。含有 UDF 的互動式查詢也會計入互動式查詢的並行限制。這項限制不適用於 GoogleSQL 查詢。
每日查詢大小上限 無限制 根據預設，每日查詢大小沒有限制。不過，您可以建立自訂配額，控管每日查詢用量或每位使用者每日查詢用量，藉此限制使用者可查詢的資料量。
每日目的地資料表更新次數上限 請參閱每日最多可執行的資料表作業數。 查詢作業中目的地資料表的更新次數，會計入目的地資料表每日最多可執行的資料表作業次數限制。目的地資料表更新包括附加和覆寫作業，這些作業是由您透過 Google Cloud 控制台、bq 指令列工具或呼叫 jobs.query 和查詢類型 jobs.insert API 方法執行的查詢所觸發。
查詢/多重陳述式查詢執行時間限制 6 小時

查詢或多重陳述式查詢最多可執行 6 小時，然後就會失敗。不過，如果發生暫時性問題 (例如伺服器重新啟動)，BigQuery 可能會在內部重試查詢工作。BigQuery 最多可嘗試執行查詢三次，每次嘗試最多可執行 6 小時。因此，查詢的總執行時間可能超過 6 小時 (最多 18 小時)。

如要確認作業是否已重試，可以查看下列信號：

  • Google Cloud 控制台：在工作探索工具中，比較兩項工作。在「查詢層級分析」部分，勾選「指標」分頁中的「重試」欄位。
  • INFORMATION_SCHEMA：在INFORMATION_SCHEMA.JOBS 檢視畫面中，檢查 final_execution_duration_ms 欄。如果 start_time 和 end_time 之間的差異遠大於 final_execution_duration_ms，則表示查詢已重試。
  • BigQuery API：在 JobStatistics 物件中，檢查 finalExecutionDurationMs 欄位。如果 startTime 和 endTime 之間的差異遠大於 finalExecutionDurationMs，則表示查詢已重試。

詳情請參閱查詢疑難排解說明文件中的「執行時間」。

CREATE MODEL工作逾時預設為 24 小時，但時間序列、AutoML 和超參數調整工作除外，這類工作會在 48 小時後逾時。
每個查詢參照的資源數量上限 1,000 項資源 查詢在完全展開後，最多可參照 1,000 個不重複的資料表、不重複的檢視區塊、不重複的 使用者定義函式 (UDF) 和不重複的資料表函式。這項限制包括：
  • 查詢直接參照的資料表、檢視區塊、UDF 和資料表函式。
  • 其他檢視區塊/UDF/資料表函式參照的資料表、檢視區塊、UDF 和資料表函式。
SQL 查詢的字元長度上限 1,024k 個字元 SQL 查詢的長度上限為 1,024k 個字元。這項限制包括註解和空白字元。如果查詢過長，您會收到下列錯誤訊息：The query is too large.如要遵守這項限制，請考慮使用查詢參數取代大型陣列或清單，並將長查詢分成工作階段中的多個查詢。
未解決的舊版 SQL 查詢長度上限 256 KB 未解析的舊版 SQL 查詢長度上限為 256 KB。如果查詢過長，您會收到下列錯誤訊息：The query is too large. 如要符合這項限制，請考慮以查詢參數取代大型陣列或清單。
未解析的 GoogleSQL 查詢長度上限 1 MB 未解決的 GoogleSQL 查詢長度上限為 1 MB。如果查詢過長，您會收到下列錯誤訊息：The query is too large. 如要符合這項限制，請考慮以查詢參數取代大型陣列或清單。
已解析的舊版和 GoogleSQL 查詢長度上限 12 MB 已解析查詢長度的限制包括查詢參照的所有檢視區塊和萬用字元資料表長度。
GoogleSQL 查詢參數數量上限 10,000 個參數 GoogleSQL 查詢最多可有 10,000 個參數。
要求大小上限 10 MB 要求大小最多可達 10 MB，包括查詢參數等其他屬性。
回應大小上限 10 GB 壓縮檔 大小會因資料的壓縮比而異。實際回應大小可能遠大於 10 GB。將大型查詢結果寫入目的地資料表時，回應大小上限不受限制。
資料列大小上限 100 MB 資料列大小上限為近似值，因為上限是根據資料列資料的內部表示法而定。在查詢作業的特定執行階段，系統會強制執行資料列大小上限。
資料表、查詢結果或檢視定義中的資料欄數上限 10,000 欄 資料表、查詢結果或檢視定義最多可有 10,000 欄。包括巢狀和重複的資料欄。已刪除的欄仍會計入欄總數。如果您刪除欄，配額錯誤可能會持續發生，直到總數重設為止。
以量計價的運算單元數量上限 每個專案 2,000 個運算單元

每個機構 20,000 個運算單元 		透過以量計價的方式，您的專案最多可以有 2,000 個並行運算單元。 此外，組織層級的並行時段上限為 20,000 個。 如果機構內專案的總需求量超過 20,000 個運算單元，BigQuery 會嘗試在專案之間公平分配運算單元。BigQuery 運算單元會由單一專案中的所有查詢共用。BigQuery 可能會超出這個限制，藉此加快查詢速度。實際容量視可用資源而定。 如要查看使用的時段數，請參閱「使用 Cloud Monitoring 監控 BigQuery」。
以量計價模式下，掃描資料的 CPU 使用量上限 每掃描 1 MiB 的資料，需要 256 秒的 CPU 時間 以量計價時，查詢每掃描 1 MiB 的資料，最多可使用約 256 秒的 CPU 時間。如果查詢處理的資料量過大，導致 CPU 負荷過重，查詢就會失敗並顯示 billingTierLimitExceeded 錯誤。 詳情請參閱「 錯誤訊息」。
多陳述式交易表異動 100 個表格 最多只能在 100 個資料表中變更資料。 交易
多陳述式交易分割區修改 100,000 次分區修改 單一 交易最多可執行 100,000 項分割區修改作業。
BigQuery Omni 查詢結果大小上限 20 GiB (未壓縮) 查詢 Microsoft Azure 或 AWS 資料時，結果大小上限為 20 GiB 的邏輯位元組。如果查詢結果超過 20 GiB，請考慮將結果匯出至 Amazon S3 或 Blob Storage。詳情請參閱「BigQuery Omni 限制」一文。
BigQuery Omni 每日查詢結果總大小 1 TB 專案的每日查詢結果總大小為 1 TB。 詳情請參閱「BigQuery Omni 限制」。
BigQuery Omni 的最大資料列大小 10 MiB 查詢 Microsoft Azure 或 AWS 資料時，資料列大小上限為 10 MiB。詳情請參閱「BigQuery Omni 限制」一文。
轉移全域查詢 2 GiB/秒 每個專案、每個區域配對的全域查詢所用傳輸頻寬

雖然排程查詢會使用 BigQuery 資料移轉服務的功能，但排程查詢並非移轉作業，因此不受載入工作限制。

擷取工作

使用 bq 指令列工具、 Google Cloud 控制台或 extract 類型的 jobs.insert API 方法，從 BigQuery 擷取資料時，適用下列限制。

限制 預設 附註
每日擷取的位元組數上限 50 TiB 每日 50 TiB 的限制 (ExtractBytesPerDay) 是濫用防範限制，僅適用於使用免費共用運算單元集區的擷取作業。使用共用運算單元集區，即可每日從專案擷取最高 50 TiB 的資料，無須支付費用。您可以設定 Cloud Monitoring 警告政策，在擷取的位元組數達到特定門檻時接收通知。

擷取作業不受 50 TiB 的每日上限限制，如果符合下列任一條件，即可超過上限：
  • 建立運算單元預留項目或使用現有的預留項目，然後指派專案給工作類型為 PIPELINE 的預留項目。由於擷取工作使用的是專屬或自動調整的運算單元容量，而非共用集區，因此不會受到每日 50 TiB 配額限制。系統會採用以運算資源為準的計價模式向您收費。EXPORT DATA 陳述式不支援PIPELINE預訂。
  • 使用 EXPORT DATA SQL 陳述式。由於這項陳述式會以查詢作業的形式執行，並使用查詢容量而非共用擷取集區，因此不受擷取位元組配額限制。系統會根據專案的設定方式，採用以量計價或以運算量為準的計價模式，向您收取費用。
  • 使用 Storage Read API。 由於串流讀取作業會直接從 BigQuery 儲存空間讀取資料，因此不會計入擷取作業配額。系統會按照串流讀取的價格計費。系統保證有效期限至少為工作階段建立時間後的 6 小時。
每日擷取工作數量上限 100,000 項擷取工作 每天 10 萬項擷取工作的限制是為了防止濫用，僅適用於使用免費共用運算單元集區的擷取工作。使用共用運算單元集區，即可在專案中每天執行最多 100,000 項擷取作業，無須支付費用。

擷取工作不受每日 100,000 項工作限制，只要符合下列任一條件，即可超過限制：
單一檔案可擷取的表格大小上限 1 GB 您最多可將 1 GB 的表格資料擷取至單一檔案。如要擷取超過 1 GB 的資料，請使用 萬用字元將資料擷取至多個檔案。將資料擷取至多個檔案時，檔案大小會有所不同。在某些情況下，輸出檔案的大小會超過 1 GB。
每個擷取作業的 萬用字元 URI 500 個 URI 擷取工作最多可有 500 個萬用字元 URI。

如要進一步瞭解如何查看目前的擷取作業用量，請參閱「查看目前的配額用量」。如需疑難排解資訊，請參閱「匯出疑難排解」。

載入工作

使用Google Cloud 控制台、bq 指令列工具或載入類型 jobs.insert API 方法將資料載入 BigQuery 時，適用下列限制。

限制 預設 附註
每天每個資料表載入的作業數 1,500 項工作 載入作業 (包括失敗的載入作業) 會計入目的地資料表的每日資料表作業次數上限。如要瞭解標準資料表和分區資料表每日可執行的資料表作業數量限制，請參閱「資料表」。
每日載入工作數 100,000 項工作 專案每 24 小時最多可補充 100,000 個載入工作配額。 失敗的載入工作會計入這項限制。在某些情況下，如果前一天的配額未完全用盡，您可以在 24 小時內執行超過 10 萬項載入作業。
每個表格的欄數上限 10,000 欄 資料表最多可有 10,000 個資料欄。包括巢狀和重複的資料欄。
每個載入工作的最大大小 15 TB 所有 CSV、JSON、Avro、Parquet 和 ORC 輸入檔案的總大小最多可達 15 TB。這項限制不適用於有預訂的作業。
工作設定中的來源 URI 數量上限 10,000 個 URI 工作設定最多可有 10,000 個來源 URI。
每個載入工作的檔案數量上限 10,000,000 個檔案 載入作業最多可包含 1000 萬個檔案，包括符合所有萬用字元 URI 的所有檔案。
來源 Cloud Storage bucket 中的檔案數量上限 約 6,000 萬個檔案 載入工作可從 Cloud Storage bucket 讀取最多約 6,000 萬個檔案。
載入工作執行時間限制 6 小時 如果載入作業執行時間超過六小時，就會失敗。
Avro：檔案資料區塊大小上限 16 MB Avro 檔案資料區塊的大小上限為 16 MB。
CSV：儲存格大小上限 100 MB CSV 儲存格大小上限為 100 MB。
CSV：列大小上限 100 MB CSV 列的大小上限為 100 MB。
CSV：檔案大小上限 - 壓縮 4 GB 壓縮 CSV 檔案的大小上限為 4 GB。
CSV：檔案大小上限 - 未壓縮 5 TB 未壓縮 CSV 檔案的大小上限為 5 TB。
以換行符號分隔的 JSON (ndJSON)：最大列大小 100 MB ndJSON 列的大小上限為 100 MB。
ndJSON：檔案大小上限 - 已壓縮 4 GB 壓縮 ndJSON 檔案的大小上限為 4 GB。
ndJSON：檔案大小上限 - 未壓縮 5 TB 未壓縮 ndJSON 檔案的大小上限為 5 TB。

如果經常更新資料而導致超出載入工作限制，建議改為 將資料串流至 BigQuery。

如要瞭解如何查看目前的載入作業用量，請參閱「查看目前的配額用量」。

BigQuery 資料移轉服務載入工作配額注意事項

BigQuery 資料移轉服務移轉作業建立的載入工作，會計入 BigQuery 的載入工作配額。請務必考量每個專案中啟用的轉移數量，以免轉移和其他載入作業產生 quotaExceeded 錯誤。

您可以使用以下公式估算移轉作業所需的載入工作數量：

Number of daily jobs = Number of transfers x Number of tables x Schedule frequency x Refresh window

在上述公式中：

  • Number of transfers 是您在專案中啟用的移轉作業設定檔數量。

  • Number of tables 是各個移轉作業類型建立的資料表數量，資料表數量因移轉作業的類型而異：

    • Campaign Manager 移轉作業會建立大約 25 個資料表。
    • Google Ads 移轉作業會建立大約 60 個資料表。
    • Google Ad Manager 移轉作業會建立大約 40 個資料表。
    • Google Play 移轉作業會建立大約 25 個資料表。
    • Search Ads 360 移轉作業會建立大約 50 個資料表。
    • YouTube 移轉作業會建立大約 50 個資料表。

  • Schedule frequency 說明了移轉作業的執行頻率。視移轉作業類型而定，移轉作業的執行時間表可能不同：

  • Refresh window 是資料移轉作業中包含的天數，輸入 1 即代表不會每日執行補充作業。

複製工作

下列限制適用於複製資料表的 BigQuery 工作，包括建立標準資料表、資料表副本、資料表副本或資料表快照的工作。這些限制適用於使用 Google Cloud 控制台、bq 指令列工具或jobs.insert 方法建立的工作，這些方法會在工作設定中指定 copy 欄位。無論複製作業成功與否，都會計入這些限制。

限制 預設 附註
每天複製每個目的地資料表的工作 請參閱「每日表格作業」。
每天可複製的工作數 100,000 項工作 每個專案每天最多可執行 100,000 項複製作業。
每個目的地資料表每天的跨區域複製工作數 100 個職缺 每個專案每天最多可為每個目的地表格執行 100 項跨區域複製作業。
每日跨區域複製作業 2,000 項工作 您的專案每天最多可執行 2,000 個跨區域複製作業。
要複製的來源資料表數量 1,200 個來源資料表 每個複製作業最多可複製 1,200 個來源資料表。

如要瞭解如何查看目前的複製作業用量，請參閱「複製作業 - 查看目前的配額用量」。如需複製工作疑難排解資訊，請參閱「每個專案每日複製工作數量上限配額錯誤」。

複製資料集時，請遵守下列限制：

限制 預設 附註
來源資料集中的表格數量上限 25,000 個資料表 來源資料集最多可有 25,000 個資料表。
每次執行作業時，可複製到同一區域目標資料集的資料表數量上限 20,000 個資料表 每個專案每次最多可將 20,000 個資料表複製到相同區域的目標資料集。如果來源資料集包含超過 20,000 個資料表，BigQuery 資料移轉服務會排定連續執行作業，每次複製最多 20,000 個資料表，直到所有資料表都複製完畢為止。這些執行作業會以 24 小時的預設間隔分開執行，使用者可自訂間隔，最短為 12 小時。
每次執行作業時，可複製到不同區域目的地資料集的資料表數量上限 1,000 個資料表 每個專案每次最多可將 1,000 個資料表複製到其他區域的目的地資料集。如果來源資料集包含超過 1,000 個資料表，BigQuery 資料移轉服務會排定連續執行作業，每次複製最多 1,000 個資料表，直到所有資料表都複製完畢為止。這些執行作業之間預設間隔 24 小時，使用者可自訂間隔，最短為 12 小時。

預留項目

下列配額適用於預訂：

配額 預設 附註
歐盟區域的總時段數 5,000 個運算單元 使用 Google Cloud 控制台在歐盟多區域購買 BigQuery 運算單元時，
在 Google Cloud 控制台中查看配額
美國區域的運算單元總數 10,000 個運算單元 使用 Google Cloud 控制台在美國多區域購買 BigQuery 運算單元時，最多可購買的數量。
在 Google Cloud 控制台中查看配額
us-east1 區域的總空位數 4,000 個運算單元 您可以使用 Google Cloud 控制台，在列出的區域購買的 BigQuery 運算單元數量上限。
在 Google Cloud 控制台中查看配額
下列區域的運算單元總數：
  • asia-south1
  • asia-southeast1
  • europe-west2
  • us-central1
  • us-west1
 2,000 個運算單元 使用 Google Cloud 控制台，在每個列出的區域中可購買的 BigQuery 運算單元數量上限。
在 Google Cloud 控制台中查看配額
下列區域的運算單元總數：
  • asia-east1
  • asia-northeast1
  • asia-northeast3
  • asia-southeast2
  • australia-southeast1
  • europe-north1
  • europe-west1
  • europe-west3
  • europe-west4
  • northamerica-northeast1
  • us-east4
  • southamerica-east1
 1,000 個運算單元 使用 Google Cloud 控制台，在每個列出的區域中可購買的 BigQuery 運算單元數量上限。
在 Google Cloud 控制台中查看配額
BigQuery Omni 區域的運算單元總數 100 個運算單元 使用 Google Cloud 控制台，在 BigQuery Omni 區域購買的 BigQuery 運算單元數量上限。
在 Google Cloud 控制台中查看配額
所有其他區域的總時段數 500 個運算單元 您可以使用 Google Cloud 控制台，在每個其他區域購買的 BigQuery 運算單元數量上限。
在 Google Cloud 控制台中查看配額

預訂有以下限制：

限制 值 附註
運算單元預留項目的 管理專案數量 每個機構 10 個專案 組織內可包含特定位置/區域的預留項目或運算單元有效承諾的專案數量上限。
標準版預留項目數量上限 每項專案最多 10 個預留項目 機構中每個管理專案在特定位置 / 區域的 Standard 版預留項目數量上限。
Enterprise 或 Enterprise Plus 版的預留項目數量上限 每個專案 200 個預留項目 每個管理專案在特定位置 / 區域的 Enterprise 或 Enterprise Plus 版本預留項目數量上限。
與工作類型為 CONTINUOUS 的預留項目指派項目相關聯的預留項目運算單元數量上限。 500 個運算單元 如要建立工作類型為 CONTINUOUS 的預約指派項目，相關聯的預約不得超過 500 個時段。

資料集

下列限制適用於 BigQuery資料集：

限制 預設 附註
資料集數量上限 無限制 專案可擁有的資料集數量沒有上限。
每個資料集的資料表數量 無限制 使用 API 呼叫時，當資料集中的資料表接近 50,000 個時，列舉作業的效能就會變慢。 Google Cloud 控制台最多可為每個資料集顯示 50,000 個資料表。
資料集存取控制清單中的授權資源數量 2,500 項資源

資料集的存取控制清單最多可有 2,500 個授權資源，包括授權檢視區塊、授權資料集和授權函式。 如果授權檢視區塊數量過多而超出上限，建議將檢視區塊分組到授權資料集中。 設計新的 BigQuery 架構 (尤其是多租戶架構) 時，建議將相關檢視區塊分組到授權資料集中。
每 10 秒每個資料集可執行的資料集更新作業數 5 項作業 專案每 10 秒最多可執行五項資料集更新作業。 資料集更新次數上限包含下列項目執行的所有中繼資料更新作業：
資料集說明長度上限 16,384 個半形字元 為資料集新增說明時，文字長度不得超過 16,384 個字元。

資料表

所有資料表

下列限制適用於所有 BigQuery 資料表。

限制 預設 附註
資料欄名稱長度上限 300 個半形字元 欄名不得超過 300 個半形字元。
資料欄說明長度上限 1,024 個半形字元 為資料欄新增說明時，文字長度不得超過 1,024 個半形字元。
巢狀記錄的最大深度 15 個等級 RECORD 類型的資料欄可以包含巢狀 RECORD 型別，也稱為子項記錄。巢狀結構深度上限為 15 層。 無論記錄是純量還是以陣列為基礎 (重複)，都會受到這項限制。
資料表說明的長度上限 16,384 個半形字元 為表格新增說明時，文字長度不得超過 16,384 個半形字元。

如需資料表配額或限制的疑難排解資訊，請參閱 BigQuery 疑難排解頁面。

標準資料表

BigQuery 標準 (內建)資料表有下列限制：

限制 預設 附註
每日資料表修改次數 1,500 項修改

每個專案每天最多可修改每個資料表 1,500 次。 載入工作、複製工作或 查詢工作，只要附加或覆寫資料表資料，都算做一次資料表修改。這個限制無法變更。

這項限制會在一天中以速率限制的形式強制執行，而不是一次性分配的單一配額。BigQuery 會定期補充可用配額。如果作業頻率過高，可能會耗盡可用配額，導致發生 quotaExceeded 錯誤，即使每日總量遠低於 1,500 項修改的每日上限也是如此。

如要提高高頻率擷取作業的效率，請考慮批次處理作業、在一段時間內平均分配工作，或遷移至 BigQuery Storage Write API (gRPC)。

系統會排除 DML 陳述式，且不會計入每日的資料表修改次數。

系統會排除串流資料，且不會計入每日的資料表修改次數。
每個資料表的中繼資料更新作業最高速率 每 10 秒 5 項作業 每個資料表每 10 秒最多可進行五項資料表中繼資料更新作業。這項限制適用於下列項目執行的所有資料表的中繼資料更新作業： 這項限制也包括所有載入作業、複製作業和查詢作業的總和，這些作業會附加至或覆寫目的地資料表，或是使用 DML DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 陳述式將資料寫入資料表。請注意，DML 陳述式會計入這項限制，但如果達到限制，就不會受到影響。DML 作業有專屬的速率限制。

如果超過這項限制，您會收到類似「Exceeded rate limits: too many table update operations for this table」的錯誤訊息。這項錯誤是暫時性的，您可以以指數輪詢方式重試。

如要找出計入這項限制的作業，可以 檢查記錄檔。如要瞭解如何診斷及解決這項錯誤，請參閱「排解配額錯誤」。

每個資料表最多可有幾欄 10,000 欄 每個資料表、查詢結果或檢視定義最多可有 10,000 欄。包括巢狀和重複的資料欄。

外部資料表

如果 BigQuery 資料表中的資料是以 Parquet、ORC、Avro、CSV 或 JSON 格式儲存在 Cloud Storage，則適用下列限制：

限制 預設 附註
每個外部資料表的來源 URI 數量上限 10,000 個 URI 每個外部資料表最多可有 10,000 個來源 URI。
每個外部資料表的檔案數量上限 10,000,000 個檔案 外部資料表最多可有 1 千萬個檔案，包括符合所有萬用字元 URI 的所有檔案。
每個外部資料表在 Cloud Storage 中儲存的資料大小上限 600 TB 所有輸入檔案加總起來，外部資料表最多可達 600 TB。這項限制適用於儲存在 Cloud Storage 中的檔案大小，與查詢定價公式中使用的檔案大小不同。如果是外部分區資料表，系統會在 修剪分區後套用限制。
來源 Cloud Storage bucket 中的檔案數量上限 大約 3 億個檔案 外部資料表最多可參照約 3 億個檔案所在的 Cloud Storage bucket。如果是 外部 分區資料表，系統會在 分區修剪前套用這項限制。

分區資料表

以下限制適用於 BigQuery 分區資料表。

分區限制適用於所有載入工作、複製工作和查詢工作的總和，這些工作會附加至或覆寫目的地分區。

單一工作可能會影響多個分割區。舉例來說，查詢工作和載入工作可以寫入多個分割區。

BigQuery 會根據作業影響的分區數量，判斷作業消耗的限制量。串流插入作業不會影響這項限制。

如要瞭解如何採取策略，確保分割資料表不超過限制，請參閱「 排解配額錯誤」。

限制 預設 附註
每個分區資料表的分區數量 10,000 個分區 每個已分割的表格最多可有 10,000 個分割區。如果超出這個限制，建議除了分區外，也考慮使用 分群，或改用分群。
單一工作修改的分區數量 4,000 個分割區 每個工作作業 (查詢或載入) 最多可影響 4,000 個資料分割。 如果查詢或載入工作嘗試修改超過 4,000 個分割區，BigQuery 會拒絕執行。
每個分區資料表每天在擷取時間修改的分區數 11,000 項修改

專案每天最多可進行 11,000 次分割區修改。

分區修改是指在分區資料表中附加、更新、刪除或截斷資料。每種資料修改都會計為一次分割區修改。舉例來說，刪除一列算是一次分區修改，刪除整個分區也算是一次修改。如果您從一個分割區刪除資料列，然後插入另一個分割區，這會計為兩次分割區修改。

使用 DML 陳述式或串流 API 進行的修改，不會計入每日分割區修改次數。
每天每個按資料欄分區的資料表的分區修改次數 30,000 項修改

對於以資料欄分區的資料表，專案每天最多可進行 30,000 次分區修改。

DML 陳述式不會計入每日修改的分割區數量。

串流資料不會計入每日分區修改次數。
每個分區資料表的中繼資料更新作業最高速率 每 10 秒 50 次修改 每個專案每 10 秒最多可對每個已分割的資料表進行 50 次修改。這項限制適用於下列項目執行的所有分割資料表的中繼資料更新作業： 這項限制也包括所有載入作業、複製作業和查詢作業的總和，這些作業會附加至或覆寫目的地資料表，或是使用 DML DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 陳述式將資料寫入資料表。

如果超過這項限制，您會收到類似「Exceeded rate limits: too many partitioned table update operations for this table」的錯誤訊息。這項錯誤是暫時性的，您可以以指數輪詢方式重試。

如要找出計入這項限制的作業，可以 檢查記錄檔。
範圍分區的可能範圍數量 10,000 個範圍 範圍分區資料表最多可有 10,000 個可能的範圍。 建立資料表時，這項限制會套用至分區規格。建立資料表後，實際分區數量也會受到限制。

資料表本機副本

BigQuery 資料表副本有以下限制：

限制 預設 附註
鏈結中的複製和快照數量上限 3 個資料表本機副本或快照 複製和快照的組合最多只能有 3 層。複製或建立基礎資料表的快照時，您只能再複製或建立結果兩次；嘗試第三次複製或建立結果快照時，會發生錯誤。舉例來說，您可以建立基礎資料表的副本 A，然後建立副本 A 的快照 B，再建立快照 B 的副本 C。如要建立第三層複製或快照的額外副本，請改用複製作業。
基礎資料表的副本和快照數量上限 1,000 個資料表本機副本或快照 特定基礎資料表最多只能有 1,000 個現有複製和快照。舉例來說，如果您有 600 個快照和 400 個副本，就會達到上限。

資料表快照

BigQuery資料表快照有下列限制：

限制 預設 附註
並行資料表快照工作數量上限 100 個職缺 您的專案最多可同時執行 100 項表格快照作業。
每日最多可執行多少個資料表快照工作 50,000 項工作 您的專案每天最多可執行 50,000 個表格快照工作。
每個資料表每天最多可執行的資料表快照工作數 50 項工作 每個專案每天最多可為每個資料表執行 50 項資料表快照作業。
每 10 秒內，每個資料表快照的中繼資料更新次數上限。 5 則更新 專案每 10 秒最多可更新表格快照的中繼資料五次。
鏈結中的複製和快照數量上限 3 個資料表本機副本或快照 複製和快照的組合最多只能有 3 層。複製或建立基礎資料表的快照時，您只能再複製或建立結果兩次；嘗試第三次複製或建立結果快照時，會發生錯誤。舉例來說，您可以建立基礎資料表的副本 A，然後建立副本 A 的快照 B，再建立快照 B 的副本 C。如要建立第三層複製或快照的額外副本，請改用複製作業。
基礎資料表的副本和快照數量上限 1,000 個資料表本機副本或快照 特定基礎資料表最多只能有 1,000 個現有複製和快照。舉例來說，如果您有 600 個快照和 400 個副本，就會達到上限。

瀏覽次數

下列配額和限制適用於檢視區塊和具體化檢視區塊。

邏輯檢視表

下列限制適用於 BigQuery 標準檢視區塊：

限制 預設 附註
巢狀檢視層級數量上限 16 個等級 BigQuery 最多支援 16 個層級的巢狀檢視區塊。 您最多可以建立這麼多層級的檢視區塊，但查詢最多只能有 15 個層級。如果超過上限，BigQuery 會傳回 INVALID_INPUT 錯誤。
用來定義檢視區塊的 GoogleSQL 查詢長度上限 256 K 個字元 定義檢視區塊的單一 GoogleSQL 查詢長度不得超過 256 KB。這項限制適用於單一查詢，不包括查詢中參照的檢視區塊長度。
每個資料集的授權 view 數量上限 請參閱「資料集」。
檢視畫面說明長度上限 16,384 個半形字元 為檢視畫面新增說明時，文字長度不得超過 16,384 個字元。

具體化檢視表

下列限制適用於 BigQuery 具體化檢視表：

限制 預設 附註
基礎資料表參照 (相同專案) 100 個具體化檢視表 每個基礎資料表最多可供同一專案中的 100 個具體化檢視區塊參照。
基礎資料表參照 (整個機構) 500 個具體化檢視表 整個機構最多可有 500 個具體化檢視區塊參照每個基礎資料表。
每個資料集的授權 view 數量上限 請參閱「資料集」。
materialized view 說明長度上限 16,384 個半形字元 為具體化檢視區塊新增說明時，文字長度不得超過 16,384 個字元。
具體化檢視表重新整理作業執行時間限制 12 小時 具體化檢視區塊重新整理工作最多可執行 12 小時，之後就會失敗。

搜尋索引

下列限制適用於 BigQuery 搜尋索引：

限制 預設 附註
每個專案每天在每個區域的 CREATE INDEX 或 ALTER INDEX DDL 陳述式數量 500 項作業 您的專案每天在每個區域內最多可發出 500 項 CREATE INDEX 或 ALTER INDEX DDL 作業。
每天每個資料表的搜尋索引 DDL 陳述式數量 20 項作業 每個專案每天最多可針對每個資料表發出 20 項 CREATE INDEX、 ALTER INDEX 或 DROP INDEX DDL 作業。
機構可建立搜尋索引的表格資料總大小上限 (不透過預留項目執行) 多區域：100 TB；所有其他區域：20 TB 如果貴機構中含有索引的資料表總大小低於所在區域的限制 (US 和 EU 多區域為 100 TB，其他區域為 20 TB)，您就可以為資料表建立搜尋索引。如果索引管理工作是在您自己的預訂項目中執行，則不適用這項限制。
每個資料表以資料欄精細程度建立索引的資料欄數 每個資料表最多 63 欄 表格最多可有 63 欄，且 index_granularity 設為 COLUMN。從設定 default_index_column_granularity 選項建立索引的資料欄 (精細度為 COLUMN) 會計入這項限制。以 GLOBAL 精細度建立索引的資料欄數量沒有限制。詳情請參閱「以資料欄精細度建立索引」。

向量索引

下列限制適用於 BigQuery 向量索引：

限制 預設 附註
基礎資料表資料列數量下限 5,000 列 資料表至少要有 5,000 列，才能建立向量索引。
索引類型「IVF」的基礎資料表列數上限 10,000,000,000 列 如要建立 IVF 向量索引，資料表最多只能有 10,000,000,000 列
索引類型 TREE_AH 的基礎資料表列數上限 200,000,000 個資料列 如要建立 TREE_AH 向量索引，資料表最多只能有 200,000,000 列
基礎資料表分區索引類型的資料列數上限 TREE_AH 總共 10,000,000,000 個資料列

每個分區 200,000,000 個資料列 		每個資料表最多可有 10,000,000,000 個資料列，每個分割區最多可有 200,000,000 個資料列，以建立TREE_AH分割向量索引。
索引資料欄中陣列的大小上限 4,096 個元素 要建立索引的資料欄陣列最多可有 4,096 個元素。
填入向量索引的最小資料表大小 10 MB 如果是在小於 10 MB 的資料表上建立向量索引，系統不會填入索引。同樣地，如果從向量索引資料表刪除資料，導致資料表大小低於 10 MB，向量索引就會暫時停用。無論您是否使用自己的預留項目執行索引管理工作，都會發生這種情況。向量索引資料表的大小再次超過 10 MB 時，系統會自動填入索引。
每個專案每天在每個區域的 CREATE VECTOR INDEX DDL 陳述式數量 500 項作業 每個專案在每個區域每天最多可發出 500 項 CREATE VECTOR INDEX作業。
每個資料表每天的向量索引 DDL 陳述式數量 10 項作業 每天每張表格最多可發出 10 次 CREATE VECTOR INDEX 或 DROP VECTOR INDEX 作業。
機構可建立向量索引的資料表資料總大小上限 (不透過預留空間執行) 6 TB 如果貴機構中含有索引的資料表總大小未超過 6 TB，即可為資料表建立向量索引。如果索引管理工作是在您自己的預訂項目中執行，則不適用這項限制。

處理常式

日常安排適用下列配額和限制。

使用者定義函式

在 GoogleSQL 查詢中，臨時和永久 user-defined function (UDF) 皆適用下列限制。

限制 預設 附註
每列輸出內容上限 5 MB 處理單一資料列時，JavaScript UDF 的輸出資料量上限約為 5 MB。
使用 JavaScript UDF 的舊版 SQL 查詢並行數量上限 6 項查詢 專案最多可同時執行六個包含 JavaScript UDF 的舊版 SQL 查詢。這項限制包括互動式和批次查詢。 這項限制不適用於 GoogleSQL 查詢。
每個查詢的 JavaScript UDF 資源數量上限 50 項資源 查詢作業最多可有 50 個 JavaScript UDF 資源，例如內嵌程式碼 Blob 或外部檔案。
內嵌程式碼 Blob 大小上限 32 KB UDF 中的內嵌程式碼 Blob 大小上限為 32 KB。
每個外部程式碼資源的大小上限 1 MB 每個 JavaScript 程式碼資源的大小上限為 1 MB。

永久 UDF 有以下限制：

限制 預設 附註
使用者定義函式名稱長度上限 256 個半形字元 UDF 名稱的長度上限為 256 個字元。
引數數量上限 256 個引數 UDF 最多可有 256 個引數。
引數名稱長度上限 128 個半形字元 UDF 引數名稱長度上限為 128 個字元。
UDF 參照鏈結的最大深度 16 筆參照資料 UDF 參照鏈最多可有 16 個參照。
STRUCT 型別引數或輸出內容的最大深度 15 個等級 STRUCT 型別 UDF 引數或輸出內容最多可有 15 個層級。
每個 UDF 的 STRUCT 型別引數或輸出內容中的欄位數量上限 1,024 個欄位 UDF 的 STRUCT 型別引數和輸出內容最多可有 1024 個欄位。
CREATE FUNCTION陳述式中的 JavaScript 程式庫數量上限 50 個程式庫 一個 CREATE FUNCTION 陳述式最多可有 50 個 JavaScript 程式庫。
所含 JavaScript 程式庫路徑長度上限 5,000 個字元 UDF 中包含的 JavaScript 程式庫路徑長度上限為 5,000 個字元。
每 10 秒每個 UDF 的更新率上限 5 則更新 專案每 10 秒最多可更新 UDF 五次。
每個資料集可授權的 UDF 數量上限 請參閱「資料集」。
Python UDF：每個專案和區域的圖片儲存位元組數 10 GiB 特定專案和區域中，Python UDF 使用的所有容器映像檔總大小 (以位元組為單位)。
Python UDF：修改作業限制 每分鐘 30 次 每個專案的每個區域，每分鐘最多可建立或更新 30 次 Python UDF。
Python UDF：並行 Python UDF 數量上限 10 每個專案最多可以同時執行 10 項參照 Python UDF 的查詢。

遠端函式

下列限制適用於 BigQuery 中的遠端函式。

如需疑難排解資訊，請參閱「含有遠端函式的並行查詢數量上限」。

限制 預設 附註
包含遠端函式的並行查詢數量上限 10 項查詢 每個專案最多可使用 遠端函式執行十項並行查詢。
輸入內容大小上限 5 MB 單一資料列中所有輸入引數的總大小上限為 5 MB。
HTTP 回應大小限制 (Cloud Run 函式第 1 代) 10 MB Cloud Run 函式第 1 代的 HTTP 回應主體大小上限為 10 MB。如果超過這個值，查詢就會失敗。
HTTP 回應大小限制 (Cloud Run functions 第 2 代或 Cloud Run) 15 MB Cloud Run 函式第 2 代或 Cloud Run 的 HTTP 回應主體大小上限為 15 MB。如果超過這個值，查詢就會失敗。
HTTP 叫用時間上限 (Cloud Run 函式第 1 代) 9 分鐘 您可以為個別 HTTP 呼叫設定 Cloud Run 函式第 1 代的時間限制，但時間限制最多為 9 分鐘。 如果超過為第 1 代 Cloud Run 函式設定的時間限制，可能會導致 HTTP 叫用失敗和查詢失敗。
HTTP 叫用時間限制 (Cloud Run 函式第 2 代或 Cloud Run) 20 分鐘 個別 HTTP 叫用第 2 代 Cloud Run 函式或 Cloud Run 的時間限制。 超過這個值可能會導致 HTTP 叫用失敗和查詢失敗。
HTTP 叫用重試次數上限 20 對 Cloud Run 函式 (第 1 代、第 2 代或 Cloud Run) 的個別 HTTP 叫用作業，最多可重試的次數。超過這個值可能會導致 HTTP 叫用失敗和查詢失敗。

資料表函式

下列限制適用於 BigQuery資料表函式：

限制 預設 附註
資料表函式名稱的長度上限 256 個字元 資料表函式的名稱長度上限為 256 個字元。
引數名稱長度上限 128 個字元 資料表函式引數名稱的長度上限為 128 個字元。
引數數量上限 256 個引數 資料表函式最多可有 256 個引數。
資料表函式參照鏈結的深度上限 16 個參照 資料表函式參照鏈最多可有 16 個參照。
STRUCT 型別引數或輸出的最大深度 15 個等級 資料表函式的 STRUCT 引數最多可有 15 個層級。同樣地，資料表函式輸出內容中的 STRUCT 記錄最多可有 15 個層級。
每個資料表函式中，引數或傳回資料表 (型別為 STRUCT) 的欄位數量上限 1,024 個欄位 資料表函式的 STRUCT 引數最多可有 1,024 個欄位。同樣地，資料表函式輸出內容中的 STRUCT 記錄最多可有 1,024 個欄位。
回傳資料表中的欄數上限 1,024 欄 資料表函式傳回的資料表最多可有 1,024 個資料欄。
傳回資料表資料欄名稱的長度上限 128 個字元 傳回表格中的欄名長度上限為 128 個字元。
每 10 秒每個資料表函式的更新次數上限 5 則更新 專案每 10 秒最多可更新表格函式五次。

預存 Apache Spark 程序

下列限制適用於 Apache Spark 適用的 BigQuery 預存程序：

限制 預設 注意事項
並行預存程序查詢數量上限 50 每個專案最多可同時執行 50 個預存程序查詢。
使用中的 CPU 數量上限 12,000 每個專案最多可使用 12,000 個 CPU。已處理的查詢不會計入這項限制。

每個專案的每個位置最多可使用 2,400 個 CPU，但下列位置除外：

  • asia-south2
  • australia-southeast2
  • europe-central2
  • europe-west8
  • northamerica-northeast2
  • southamerica-west1

在這些地點，每個專案的每個地點最多可使用 500 個 CPU。

如果您在多區域位置和同一地理區域的單一區域位置中執行並行查詢，查詢可能會耗用相同的並行 CPU 配額。
使用中標準永久磁碟的總大小上限 204.8 TB

每個專案的每個位置最多可使用 204.8 TB 的標準 Persistent Disk。已處理的查詢不會計入這項限制。

如果您在多區域位置和位於同一地理區域的單一區域位置中，同時執行查詢，則查詢可能會耗用相同的標準永久磁碟配額。

筆記本

所有 Dataform 配額和限制，以及 Colab Enterprise 配額和限制，都適用於 BigQuery 中的筆記本。此外，也適用下列限制：

限制 預設 注意事項
筆記本大小上限 20 MB

筆記本的大小是內容、中繼資料和編碼額外用量的總和。

如要查看筆記本內容大小，請展開筆記本標題，依序點選「查看」和「筆記本資訊」。
每秒傳送至 Dataform 的要求數量上限 100 筆記本是透過 Dataform 建立及管理。 建立或修改記事本的任何動作都會計入這項配額。 這項配額與已儲存的查詢共用。舉例來說，如果您在 1 秒內對筆記本和已儲存的查詢各進行 50 項變更，就會達到配額上限。

已儲存的查詢

所有 Dataform 配額和限制均適用於已儲存的查詢。此外，也適用下列限制：

限制 預設 注意事項
已儲存的查詢大小上限 10 MB
每秒傳送至 Dataform 的要求數量上限 100 已儲存的查詢是透過 Dataform 建立及管理。 建立或修改已儲存的查詢的任何動作，都會計入這項配額。這項配額會與筆記本共用。舉例來說，如果您在 1 秒內對筆記本和已儲存的查詢各進行 50 項變更，就會達到配額上限。

資料操縱語言

下列限制適用於 BigQuery資料操縱語言 (DML) 陳述式：

限制 預設 附註
每日 DML 陳述式 無限制 專案每天可執行的 DML 陳述式數量沒有限制。

DML 陳述式不會計入分區資料表的每日資料表修改次數或每日分區資料表修改次數。

DML 陳述式有下列限制， 請務必留意。
每天每個資料表可同時執行的 INSERT 個 DML 陳述式 1,500 個陳述式 提交後，系統會立即執行前 1,500 條 INSERT 陳述式。達到這個上限後，寫入資料表的 INSERT 陳述式並行數會限制為 10。其他 INSERT 陳述式會新增至 PENDING 佇列。在任何時間，最多可針對資料表排入 100 個 INSERT 陳述式。當 INSERT 陳述式完成時，下一個 INSERT 陳述式會從佇列中移除並執行。

如果必須更頻繁地執行 DML INSERT 陳述式， 請考慮使用 Storage Write API (gRPC) 將資料串流至資料表。
每個資料表可同時執行的變動 DML 陳述式數量 2 個陳述式 BigQuery 最多可為每個資料表執行兩個並行的變動 DML 陳述式 (UPDATE、DELETE 和 MERGE)。資料表的其他變動 DML 陳述式會排入佇列。
每個資料表排入佇列的變動 DML 陳述式 20 個陳述式 資料表最多可有 20 個變動 DML 陳述式排入佇列，等待執行。如果您為資料表提交其他變動 DML 陳述式，這些陳述式就會失敗。
DML 陳述式的佇列時間上限 7 小時 互動式優先順序 DML 陳述式最多可在佇列中等待七小時。如果陳述式在七小時後仍未執行，就會失敗。
每個資料表的 DML 陳述式最高速率 每 10 秒 25 則陳述句 每個資料表每 10 秒最多可執行 25 個 DML 陳述式。INSERT 和變動 DML 陳述式都會計入這項限制。

如要進一步瞭解變動 DML 陳述式，請參閱「INSERT DML 並行」和「UPDATE, DELETE, MERGE DML 並行」。

多陳述式查詢

在 BigQuery 中，多重陳述式查詢有以下限制。

限制 預設 附註
並行多重陳述式查詢數量上限 1,000 次多陳述式查詢 您的專案最多可執行 1,000 個並行多陳述式查詢。
累計時間限制 24 小時 多重陳述式查詢的累計時間限制為 24 小時。
對帳單時間限制 6 小時 多重陳述式查詢中個別陳述式的時間限制為 6 小時。

查詢中的遞迴 CTE

在 BigQuery 中，遞迴一般資料表運算式 (CTE) 適用下列限制。

限制 預設 附註
疊代次數上限 500 次疊代 遞迴 CTE 可執行這個疊代次數。如果超過此上限，系統就會產生錯誤。如要避開疊代限制，請參閱「排解疊代限制錯誤」。

資料列層級安全性

下列限制適用於 BigQuery資料列層級存取政策：

限制 預設 注意事項
每個資料表可設定的資料列存取政策數量上限 400 項政策 每個表格最多可有 400 項列存取權政策。
每個查詢的資料列存取政策數量上限 6000 項政策 查詢最多可存取 6000 項資料列存取政策。
每項政策每 10 秒最多可有 CREATE / DROP 個 DDL 陳述式 5 則聲明 每 10 秒，專案最多可對每個資料列存取政策資源發出五個 CREATE 或 DROP 陳述式。
每 10 秒每個資料表 DROP ALL ROW ACCESS POLICIES 條陳述式 5 則聲明 每 10 秒，專案最多可對每個資料表發出五個 DROP ALL ROW ACCESS POLICIES 陳述式。

資料政策

資料欄層級動態資料遮蓋有以下限制：

限制 預設 附註
每個政策標記的資料政策數量上限。 每個政策標記最多可有 8 項政策 每個政策標記最多可有八項資料政策。其中一項政策可用於資料欄層級存取控管機制。系統不支援重複的遮蓋運算式。

BigQuery ML

BigQuery ML 適用下列限制。

查詢工作

所有查詢作業配額和限制，都適用於使用 BigQuery ML 陳述式和函式的 GoogleSQL 查詢作業。

CREATE MODEL 個陳述式

以下限制適用於 CREATE MODEL 工作：

限制 預設 附註
CREATE MODEL 每項專案每 48 小時的陳述式查詢數 20,000 次對帳單查詢 部分模型是透過 Vertex AI 服務訓練而成，因此有自己的資源和配額管理機制。
執行時間限制 24 或 48 小時 CREATE MODEL 工作逾時預設為 24 小時，但時間序列、AutoML 和超參數調整工作除外，這類工作會在 48 小時後逾時。

生成式 AI 功能

使用 Agent Platform 大型語言模型 (LLM) 的函式有下列限制。詳情請參閱「函式配額定義」。

每分鐘要求數限制

如果 Agent Platform 模型使用每分鐘要求數限制，則適用下列限制。

函式 模型 區域 每分鐘要求數 每個工作的列數
AI.GENERATE_TEXT

ML.GENERATE_TEXT

AI.GENERATE_TABLE

AI.GENERATE

AI.GENERATE_BOOL

AI.GENERATE_DOUBLE

AI.GENERATE_INT 		gemini-2.0-flash-lite-001 US 和 EU 多區域

gemini-2.0-flash-lite-001 中記錄的單一區域，請參閱「Google 模型端點位置」		 未設定配額。配額取決於動態共用配額 (DSQ)1 和 佈建輸送量2 佈建輸送量不適用

DSQ 為 10,500,000，適用於平均有 500 個輸入詞元和 50 個輸出詞元的通話
gemini-2.0-flash-001 US 和 EU 多區域

gemini-2.0-flash-001 中記錄的單一區域，請參閱「Google 模型端點位置」		 佈建輸送量不適用

DSQ 為 10,200,000，適用於平均有 500 個輸入詞元和 50 個輸出詞元的通話
gemini-2.5-flash US 和 EU 多區域

gemini-2.5-flash 中記錄的單一區域，請參閱「Google 模型端點位置」		 佈建輸送量不適用

DSQ 為 9,300,000，適用於平均有 500 個輸入權杖和 50 個輸出權杖的通話
gemini-2.5-pro US 和 EU 多區域

gemini-2.5-pro 中記錄的單一區域，請參閱「Google 模型端點位置」		 佈建輸送量：不適用

DSQ：7,600,000 (通話平均輸入 500 個詞元，輸出 50 個詞元)
AI.IF

AI.SCORE

AI.CLASSIFY		 各種 gemini-2.5-* 模型 US 和 EU 多區域

支援 gemini-2.5-* models 的任何單一區域 位於 Google 模型端點位置		 未設定配額。配額取決於動態共用配額 (DSQ)1 如果每列輸入內容平均有 500 個詞元，輸出內容有 50 個詞元，則為 10,000,000 個詞元。
AI.AGG 各種 Gemini 模型 請參閱「地點」 未設定配額。配額取決於動態共用配額 (DSQ)1。 20,000,000
AI.GENERATE_TEXT

ML.GENERATE_TEXT		 Anthropic Claude 請參閱各模型和區域的配額 請參閱各模型和區域的配額 每分鐘要求數值 * 60 * 6
Llama 請參閱 Llama 模型區域供應情形和配額。 請參閱 Llama 模型區域供應情形和配額。
Mistral AI 請參閱 Mistral AI 模型區域供應情形和配額 請參閱 Mistral AI 模型區域供應情形和配額
AI.GENERATE_EMBEDDING5

AI.EMBED

AI.SIMILARITY

AI.SEARCH

VECTOR_SEARCH

ML.GENERATE_EMBEDDING5		 text-embedding

text-multilingual-embedding		 支援遠端機型的所有區域 1,5003,4 如果每個輸入列平均有 50 個權杖，則為 80,000,000 個權杖

如果每個輸入列平均有 600 個權杖，則為 14,000,000 個權杖
multimodalembedding 支援的歐洲單一區域 1203 43,200
支援的歐洲單一區域以外的區域 6003 216,000
gemini-embedding-2 US、EU 和 global 未設定配額。配額取決於動態共用配額 (DSQ)1。 不適用

1 使用 DSQ 時，用量沒有預先定義的配額限制。DSQ 提供的是大型共用資源集區的存取權，並根據資源的即時供應情形和特定模型客戶需求，動態分配資源。如果活躍客戶增加，每位客戶的輸送量就會減少。同樣地，如果活躍顧客較少，每位顧客的輸送量可能會較高。

2 佈建輸送量屬於固定費用、定期訂閱方案，提供多種期限長度。您可以透過佈建輸送量，為 Agent Platform 支援的生成式 AI 模型預留處理量。

3 如要提高配額，請在 Agent Platform 中申請調整 QPM 配額。配額值增加後，請等待 30 分鐘，讓系統完成傳播。

4 您可以將 Agent Platform text-embedding 和 text-multilingual-embedding 模型的配額提高至 10,000 RPM，無須手動核准。根據每次呼叫的每個輸入資料列平均有 50 個權杖，這會使每個工作或更多工作的處理量增加 500,000,000 個資料列。

5 這項函式每個專案最多只能同時執行 5 項工作。

如要進一步瞭解 Agent Platform LLM 的配額，請參閱「Agent Platform 生成式 AI 配額限制」。

每分鐘權杖數上限

如果 Agent Platform 模型使用每分鐘權杖數限制，則適用下列限制：

功能 每分鐘的權杖數 每個工作列數 並行執行的工作數量
透過 gemini-embedding-001 模型使用遠端模型時， AI.GENERATE_EMBEDDING 或 ML.GENERATE_EMBEDDING 10,000,000 12,000,000，每列平均 300 個符記的通話 5
透過 gemini-embedding-2 模型使用遠端模型時， AI.GENERATE_EMBEDDING 或 ML.GENERATE_EMBEDDING 5,000,000 1,440,000 5

每日權杖上限

透過 BigQuery 生成式 AI 函式存取大型語言模型時，適用下列每日 Token 使用量限制。這些限制適用於全球所有地區，您可以要求調整。 詳情請參閱「使用權杖配額控管費用」。

配額名稱 指標 範圍 預設值
每日 AI 輸入權杖數 LLM 使用的輸入內容詞元 每天每項專案 200,000,000,000
每位使用者每日的 AI 輸入權杖 LLM 使用的輸入內容詞元 每位使用者每天每項專案 150,000,000,000
每天的 AI 輸出內容詞元數 LLM 使用的輸出和思考詞元 每天每項專案 20,000,000,000
每位使用者每天的 AI 輸出權杖數 LLM 使用的輸出和思考詞元 每位使用者每天每項專案 15,000,000,000

Cloud AI 服務函式

使用 Cloud AI 服務的函式有下列限制：

功能 每分鐘要求數 每個工作列數 並行執行的工作數量
ML.PROCESS_DOCUMENT 文件平均有五十頁 600 100,000 (以每份輸入文件平均 50 頁為準) 5
ML.TRANSCRIBE 200 10,000 分鐘 (以每個輸入音訊檔案的平均長度為 1 分鐘計算) 5
ML.ANNOTATE_IMAGE 1,800 648,000 5
ML.TRANSLATE 6,000 2,160,000 5
ML.UNDERSTAND_TEXT 600 21,600 5

如要進一步瞭解 Cloud AI 服務 API 的配額，請參閱下列文件：

函式配額定義

以下列出適用於生成式 AI 和 Cloud AI 服務函式的配額：

  • 呼叫 Agent Platform 模型的函式會使用一項 Agent Platform 配額，也就是每分鐘查詢次數 (QPM)。在此情境中，查詢是指函式向 Agent Platform 模型 API 發出的要求呼叫。QPM 配額適用於基礎模型，以及該模型的所有版本、ID 和微調版本。如要進一步瞭解 Agent Platform 模型配額，請參閱「Agent Platform 的生成式 AI 配額限制」。
  • 呼叫 Cloud AI 服務的函式會使用目標服務的要求配額。如要瞭解詳情，請參閱指定 Cloud AI 服務的配額參考資料。

  • BigQuery ML 使用下列配額：

    • 每分鐘要求數。這項配額是指函式每分鐘可向 Agent Platform 模型或 Cloud AI 服務的 API 發出的要求呼叫次數上限。這項限制適用於每個專案，且使用相同模型端點的所有工作都會共用這項限制。

      由於 Gemini 模型使用動態共用配額 (DSQ)，因此對 Agent Platform Gemini 模型的呼叫沒有預先定義的用量配額限制。DSQ 提供大量共用資源集區的存取權，並根據資源的即時供應情形和特定模型的需求，動態分配資源。

    • 每分鐘的權杖數。這項配額限制函式每分鐘可傳送至 Agent Platform 模型 API 的權杖數量。這項限制適用於每個專案。

      如果是呼叫 Agent Platform 基礎模型的函式，每分鐘的權杖數量會因 Agent Platform 模型端點、版本和區域而異，也會受到專案信譽的影響。這個配額在概念上與 Agent Platform 使用的 QPM 配額相同。

    • 每個工作的列數。Rows per job 值可做為效能基準，估算單一工作專用專案模型端點資源時的處理容量。實際處理的資料列數取決於多項因素，包括模型輸入要求的大小、模型輸出回應的大小，以及動態共用配額的可用性。以下範例說明一些常見情境：

      • 對於 gemini-2.0-flash-lite-001 端點，AI.GENERATE_TEXT 或 ML.GENERATE_TEXT 函式可處理的資料列數量取決於輸入和輸出權杖數。如果呼叫的平均輸入詞元數為 2,000，且輸出詞元數上限為 50，這項服務大約可處理 760 萬列。如果平均輸入詞元數為 10,000，輸出詞元數上限為 3,000，則這個數字會減少至約 100 萬列。

        同樣地，如果呼叫的平均輸入詞元數為 2,000，且輸出詞元數上限為 50，gemini-2.0-flash-001 端點可處理 440 萬列；但如果呼叫的輸入詞元數為 10,000，輸出詞元數為 3,000，則只能處理約 100 萬列。

      • 相較於長文件，ML.PROCESS_DOCUMENT 函式可處理的短文件工作列數較多。

      • 相較於長音訊片段，ML.TRANSCRIBE 函式可處理每個工作的更多資料列，適用於短音訊片段。

    • 同時執行的工作數量。這項配額是每個專案的限制，規定指定函式可同時執行的 SQL 查詢數量。

以下範例說明如何解讀一般情況下的配額限制：

  • 我在 Agent Platform 的配額為 1,000 QPM，因此含有 100,000 列的查詢應需要約 100 分鐘。為什麼工作執行時間較長？

    即使輸入資料相同，工作執行時間也可能有所不同。在 Agent Platform 中，遠端程序呼叫 (RPC) 的優先順序不同，可避免配額耗盡。如果配額不足，優先順序較低的 RPC 會等待，如果處理時間過長，可能會失敗。

  • 如何解讀每個作業的資料列配額？

    在 BigQuery 中，查詢最多可執行六小時。為確保 BigQuery 能在六小時內完成查詢處理作業，支援的資料列上限取決於這條時間軸和您的 Agent Platform QPM 配額。由於查詢通常無法用完配額，因此這個數字會比 QPM 配額乘以 360 還低。

  • 如果我在資料列數超過每個工作配額的表格上執行批次推論工作 (例如 10,000,000 列)，會發生什麼情況？

    BigQuery 只會處理工作配額中指定的資料列數。系統只會針對該筆資料列數量的成功 API 呼叫收費，而不是表格中完整的 10,000,000 筆資料列。對於其餘資料列，BigQuery 會以 A retryable error occurred: the maximum size quota per query has reached 錯誤回應要求，並在結果的 status 資料欄中傳回該錯誤。您可以使用這組 SQL 指令碼或這個 Dataform 套件，反覆進行推論呼叫，直到所有資料列都順利處理完畢為止。

  • 我要處理的資料列數量遠超過每個工作的資料列配額。將資料列分割成多個查詢並同時執行，是否能加快速度？

    否，因為這些查詢會耗用相同的 BigQuery ML 每分鐘要求配額和 Agent Platform QPM 配額。如果有多個查詢都符合每個工作的資料列配額，以及並行執行的工作數量配額，累積處理量就會用盡每分鐘要求配額。

BigQuery Graph

BigQuery Graph 有以下限制：

限制 預設 附註
圖表參照的資料表數量上限 1,000 個表格 在節點和邊緣定義中，圖形最多可參照 1,000 個節點和邊緣資料表。
每個節點或邊緣資料表的主鍵欄數上限 16 個資料欄 您可以在圖表的節點或邊緣資料表上，定義最多使用 16 個資料欄的鍵。
每個節點參照的欄數上限 16 個資料欄 來源鍵或目的地鍵最多可參照圖表中節點資料表的 16 個資料欄。
每個邊緣參照的欄數上限 16 個資料欄 邊的來源鍵或目的地鍵最多可參照邊資料表的 16 個資料欄。
圖表上的標籤數量上限 1,000 個標籤 您最多可以在圖表上定義 1,000 個節點和邊緣標籤。
每個節點或邊緣定義的標籤數量上限 20 個標籤 您可以在圖表的節點或邊緣上定義最多 20 個標籤。
圖表上定義的屬性數量上限 5,000 個屬性 您可以在圖表上定義最多 5,000 個屬性。
每個標籤定義的屬性數量上限 1,000 個資源 圖表中的每個標籤最多可定義 1,000 個屬性。

BI Engine

BigQuery BI Engine 適用下列限制。

限制 預設 附註
每個專案在每個位置的最大預留項目大小 (BigQuery BI Engine) 250 GiB 每個專案在每個位置的預留項目大小上限預設為 250 GiB。 您可以 要求提高專案的預留容量上限。大多數區域都提供預留量調高服務，視要求調高的量而定，可能需要 3 個以上的工作天。如有緊急要求，請與您的 Google Cloud代表或 Cloud Customer Care 聯絡。
每個查詢的資料列數量上限 70 億 每個查詢的資料列數量上限。

BigQuery sharing (舊稱 Analytics Hub)

BigQuery sharing (舊稱 Analytics Hub) 適用下列限制：

限制 預設 附註
每個專案的資料交換數量上限 500 次交換 一個專案最多可建立 500 個資料交換。
每個資料交換的房源數量上限 1,000 筆商店資訊 資料交換庫最多可建立 1,000 個產品資訊。
每個共用資料集可連結的資料集數量上限 1,000 個連結的資料集 所有 BigQuery sharing 訂閱者加總，每個共用資料集最多可有 1,000 個連結的資料集。

Knowledge Catalog 自動探索

Knowledge Catalog 自動探索功能有以下限制：

限制 預設 附註
探索掃描支援的每個 Cloud Storage bucket，最多可有 BigQuery、BigLake 或外部資料表 每個 bucket 最多 1000 個 BigQuery 資料表 每個 Cloud Storage bucket 最多可建立 1,000 個 BigQuery 資料表。

API 配額與限制

這些配額和限制適用於 BigQuery API 要求。

BigQuery API

下列配額適用於 BigQuery API (核心) 要求：

配額 預設 附註
每日要求數 無限制 您的專案每天可發出無限次數的 BigQuery API 要求。
在 Google Cloud 控制台中查看配額
每分鐘最多 tabledata.list 位元組 多區域：7.5 GB；所有其他區域：3.7 GB 透過 us 和 eu 多區域中的 tabledata.list，專案每分鐘最多可傳回 7.5 GB 的資料表列資料，在所有其他區域中，每分鐘最多可傳回 3.7 GB 的資料表列資料。這項配額適用於包含所讀取資料表的專案。其他 API (包括 jobs.getQueryResults，以及從 jobs.query 和 jobs.insert 擷取結果) 也會消耗這項配額。如需疑難排解資訊，請參閱「疑難排解頁面」。
在 Google Cloud 控制台中查看配額

BigQuery Storage Read API 的持續處理量遠高於 tabledata.list。如果需要比配額允許的輸送量更高，請考慮使用 BigQuery Storage Read API。

下列限制適用於 BigQuery API (核心) 要求：

限制 預設 附註
每個使用者每種方法每秒最多可發出的 API 要求數 100 個要求 使用者每秒最多可向 API 方法提出 100 項 API 要求。 如果使用者每秒對某個方法提出超過 100 項要求，系統可能會進行節流。這項限制不適用於串流插入。

如需疑難排解資訊，請參閱「疑難排解」頁面。
每個使用者並行 API 要求數量上限 300 個要求 如果使用者同時提出超過 300 項要求，系統可能會進行節流。 這項限制不適用於串流插入。
要求標頭大小上限 16 KiB BigQuery API 要求最多可達 16 KiB，包括要求網址和所有標頭。這項限制不適用於要求主體，例如 POST 要求。
每秒最多 jobs.get 個要求 1,000 項要求 您的專案每秒最多可提出 1,000 jobs.get 次要求。
jobs.query 回應大小上限 20 MB 根據預設，jobs.query 每頁結果傳回的資料列數量沒有上限。不過，回應大小上限為 20 MB。您可以使用 maxResults 參數，變更要傳回的資料列數量。
資料列大小上限 jobs.getQueryResults 20 MB 由於上限是根據資料列資料的內部表示法而定，因此資料列大小上限為近似值。轉碼期間會強制執行限制。
每秒最多 projects.list 個要求 10 項要求 使用者每秒最多可提出 10 項 projects.list 要求。
每秒最多可發出 tabledata.list 個要求 1,000 項要求 您的專案每秒最多可提出 1,000 次 tabledata.list 要求。
每個 tabledata.list 回應的列數上限 100,000 列 tabledata.list 呼叫最多可傳回 100,000 個資料表列。 詳情請參閱「參考資料：API 限制和條件」。
資料列大小上限 tabledata.list 100 MB 由於上限是根據資料列資料的內部表示法而定，因此資料列大小上限為近似值。轉碼期間會強制執行限制。
每秒最多 tables.insert 個要求 10 項要求 每位使用者每秒最多可提出 10 項 tables.insert 要求。 tables.insert 方法會在資料集中建立新的空白資料表。

BigQuery Connection API

下列配額適用於 BigQuery Connection API 請求：

配額 預設 附註
每分鐘讀取要求數 每分鐘 1,000 個要求 您的專案每分鐘最多可對 BigQuery Connection API 方法發出 1,000 項要求，以讀取連線資料。
在 Google Cloud 控制台中查看配額
每分鐘寫入要求數 每分鐘 100 個要求 您的專案每分鐘最多可對 BigQuery Connection API 方法 (用於建立或更新連線) 提出 100 項要求。
在 Google Cloud 控制台中查看配額
每分鐘建立的 BigQuery Omni 連線數 每分鐘建立 10 個連線 您的專案每分鐘最多可建立 10 個 BigQuery Omni 連線，AWS 和 Azure 總計。
BigQuery Omni 連線用途 每分鐘 500 個連線使用次數 您的專案每分鐘最多可使用 BigQuery Omni 連線 500 次。這類作業包括使用連線存取 AWS 帳戶 (例如查詢資料表)。

BigQuery Migration API

下列限制適用於 BigQuery Migration API：

限制 預設 附註
批次 SQL 翻譯的個別檔案大小 10 MB 每個來源和中繼資料檔案的大小上限為 10 MB。 這項限制不適用於 dwh-migration-dumper 指令列擷取工具產生的中繼資料 ZIP 檔案。
批次 SQL 翻譯的來源檔案總大小 1 GB 上傳至 Cloud Storage 的所有輸入檔案總大小上限為 1 GB。包括所有來源檔案，以及您選擇納入的所有中繼資料檔案。
互動式 SQL 翻譯的輸入字串大小 1 MB 您輸入的字串不得超過 1 MB，才能進行互動式 SQL 翻譯。使用 Translation API 執行互動式翻譯時，這項限制適用於所有字串輸入的總大小。
互動式 SQL 轉譯的設定檔大小上限 50 MB Cloud Storage 中的個別中繼資料檔案 (已壓縮) 和 YAML 設定檔不得超過 50 MB。如果檔案大小超過 50 MB，互動式翻譯工具會在翻譯期間略過該設定檔，並產生錯誤訊息。如要縮減中繼資料檔案大小，其中一個方法是在產生中繼資料時，使用 —database 或 –schema 旗標篩選資料庫。
每小時的 Gemini 建議數量上限 1,000 (如未使用，最多可累積 10,000) 如有需要，請與 Cloud Customer Care 聯絡，要求提高配額。

下列配額適用於 BigQuery Migration API。在大多數情況下，系統會套用下列預設值。專案的預設值可能不同：

配額 預設 附註

每分鐘的 EDWMigration 服務清單要求數

EDWMigration Service List Requests per minute per user

12,000 項要求

2,500 項要求

您的專案每分鐘最多可以提出 12,000 個 Migration API List 要求。

每位使用者每分鐘最多可發出 2,500 個 Migration API List 要求。

在 Google Cloud 控制台中查看配額

EDWMigration Service 每分鐘的 Get 要求數

EDWMigration Service Get Requests per minute per user

25,000 項要求

2,500 項要求

您的專案每分鐘最多可提出 25,000 個 Migration API Get 要求。

每位使用者每分鐘最多可發出 2,500 個 Migration API Get 要求。

在 Google Cloud 控制台中查看配額

EDWMigration Service Other Requests per minute

EDWMigration Service Other Requests per minute per user

25 項要求

5 項要求

您的專案每分鐘最多可發出 25 個其他 Migration API 要求。

每位使用者每分鐘最多可提出 5 項其他 Migration API 要求。

在 Google Cloud 控制台中查看配額

每分鐘的互動式 SQL 翻譯要求數

每位使用者每分鐘的互動式 SQL 翻譯要求數

200 項要求

50 項要求

您的專案每分鐘最多可提出 200 個 SQL 翻譯服務要求。

每位使用者每分鐘最多可提出 50 項其他 SQL 翻譯服務要求。

在 Google Cloud 控制台中查看配額

BigQuery Reservation API

下列配額適用於 BigQuery Reservation API 要求：

配額 預設 附註
各區域每分鐘的要求數 100 個要求 每個專案每分鐘最多可對每個區域的 BigQuery Reservation API 方法發出 100 次呼叫。
在 Google Cloud 控制台 查看配額
每個區域每分鐘的 SearchAllAssignments 呼叫次數 100 個要求 每個專案在每個區域每分鐘最多可對 SearchAllAssignments 方法發出 100 次呼叫。
在 Google Cloud 控制台中查看配額
每位使用者每分鐘每個區域的 SearchAllAssignments 要求數 10 項要求 每位使用者每分鐘每個區域最多可對 SearchAllAssignments 方法發出 10 次呼叫。
在 Google Cloud 控制台中查看配額
(在 Google Cloud 控制台搜尋結果中，搜尋「每個使用者」。)

BigQuery Data Policy API

以下是 Data Policy API (預先發布版) 的限制：

限制 預設 附註
dataPolicies.list 呼叫次數上限。 每項專案每分鐘 400 個要求

每個機構每分鐘 600 個要求
dataPolicies.testIamPermissions 呼叫次數上限。 每項專案每分鐘 400 個要求

每個機構每分鐘 600 個要求
讀取要求數量已達上限。 每項專案每分鐘 1200 個要求

每個機構每分鐘 1800 個要求 		這包括對 dataPolicies.get 和 dataPolicies.getIamPolicy 的呼叫。
寫入要求數量上限。 每項專案每分鐘 600 個要求

每個機構每分鐘 900 個要求

這包括對下列項目的呼叫：

IAM API

在 BigQuery 中使用「身分與存取權管理」功能擷取及設定 IAM 政策，以及測試 IAM 權限時，適用下列配額。資料控制語言 (DCL) 陳述式會計入 SetIAMPolicy 配額。

配額 預設 附註
每位使用者每分鐘 IamPolicy 個要求 每位使用者每分鐘 1,500 個要求 每位使用者每項專案每分鐘最多可提出 1,500 個要求。
在 Google Cloud 控制台中查看配額
每項專案每分鐘 IamPolicy 個要求 每項專案每分鐘 3,000 個要求 專案每分鐘最多可提出 3,000 個要求。
在 Google Cloud 控制台中查看配額
單一區域 SetIAMPolicy 每項專案每分鐘的要求數 每項專案每分鐘 1,000 個要求 單一區域專案每分鐘最多可提出 1,000 個要求。
在 Google Cloud 控制台中查看配額
多區域 每項專案每分鐘 SetIAMPolicy 個要求 每項專案每分鐘 2,000 個要求 多區域專案每分鐘最多可提出 2,000 個要求。
在 Google Cloud 控制台中查看配額
全區域 每項專案每分鐘的SetIAMPolicy要求數 每項專案每分鐘 200 個要求 Omni-region 專案每分鐘最多可提出 200 項要求。
在 Google Cloud 控制台中查看配額

Storage Read API

下列配額適用於 BigQuery Storage Read API 要求：

配額 預設 附註
每位使用者每分鐘讀取資料平面要求數 25,000 項要求 每位使用者每項專案每分鐘最多可發出 25,000 次 ReadRows 呼叫。
在 Google Cloud 控制台中查看配額
並行讀取連線數量上限 多區域為 2,000 個；區域為 400 個 每個專案的並行 ReadRows 連線數量上限。 預設值為 us和eu多區域的 2,000 個連線，以及其他區域的 400 個連線。
實際連線可用性可能會因整個區域的服務負載和需求而有所波動。這項動態調整機制可確保資源分配公平，並維持所有使用者的服務穩定性。如果串流因公平性問題而關閉，或是您達到連線上限，就會收到 RESOURCE_EXHAUSTED 錯誤 (HTTP 429)。
我們會根據專案的歷來用量模式，以及區域內資源的一般可用性，審查配額提高要求 (QIR)。
在 Google Cloud 控制台中查看配額
讀取每位使用者每分鐘的控制層要求數 5,000 項要求 每個使用者每分鐘最多可對每個專案發出 5,000 次 Storage Read API 中繼資料作業呼叫。中繼資料呼叫包括 CreateReadSession 和 SplitReadStream 方法。
在 Google Cloud 控制台中查看配額

下列限制適用於 BigQuery Storage Read API 要求：

限制 預設 附註
資料列/篩選條件長度上限 1 MB 使用 Storage Read API CreateReadSession 呼叫時，每列或篩選條件的長度上限為 1 MB。
序列化資料大小上限 128 MB 使用 Storage Read API ReadRows 呼叫時，個別 ReadRowsResponse 訊息中的資料序列化表示法不得超過 128 MB。
每個串流的記憶體用量上限 1.5 GB 由於上限是根據資料列的內部表示法而定，因此每個串流的記憶體上限為近似值。如果單一資料列使用的記憶體超過 1.5 GB，串流可能會失敗。詳情請參閱「排解資源超出限制的問題」。

Storage Write API (gRPC)

下列配額適用於 Storage Write API (gRPC) 要求。您可以在資料夾層級套用下列配額。這些配額會匯總，並在所有子專案之間共用。如要啟用這項設定，請洽詢 Cloud Customer Care 團隊。

如果您打算要求調整配額，請在要求中附上配額錯誤訊息，以加快處理速度。如果配額使用率在一年以上都明顯偏低，BigQuery 可能會調降配額。

配額 預設 附註
並行寫入連線 區域：5,000 個；多區域：20,000 個

並行連線配額是以啟動 Storage Write API (gRPC) 要求的用戶端專案為準，而非以含有 BigQuery 資料集資源的專案為準。起始專案是指與 API 金鑰或服務帳戶相關聯的專案。

您的專案可以在一個區域中處理 5,000 個並行連線，或在 US 和 EU 多個區域中處理 20,000 個並行連線。

連線應維持長時間，並盡可能用於傳送多個要求。建議不要使用存續時間較短的連線，否則可能會導致並行連線配額用量增加。為方便計算配額，建議連線生命週期至少要維持幾分鐘。

在 Java 或 Go 中使用預設串流時，建議使用儲存空間寫入 API (gRPC) 多工處理，透過共用連線寫入多個目的地資料表，以減少所需的整體連線數量。如果您使用 Beam 連接器，且語意為「至少一次」，可以將 UseStorageApiConnectionPool 設為 TRUE，啟用多路複用。

在 Google Cloud 控制台 中查看配額

您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。根據您所在的區域，選取並行連線限制名稱。us、eu 和其他地區的選項分別為 ConcurrentWriteConnectionsPerProject、ConcurrentWriteConnectionsPerProjectEU 和 ConcurrentWriteConnectionsPerProjectRegion。

強烈建議您設定快訊，監控配額用量和限制。此外，如果流量模式出現尖峰或規律的自然成長，建議考慮將配額超量配置 25% 至 50%，以處理非預期的需求。
處理量 多個區域每秒 3 GB 的處理量；區域每秒 300 MB 的處理量 在 us 和 eu 多個地區，每個專案最多可串流 3 GBps，在其他地區則為 300 MBps。
在 Google Cloud 控制台中查看配額

您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。根據您所在的區域，選取輸送量上限名稱。us、eu 和其他地區的選項分別為 AppendBytesThroughputPerProject、AppendBytesThroughputPerProjectEU 和 AppendBytesThroughputPerProjectRegion。寫入處理量配額的計量依據為目標資料集所在的專案，而非用戶端專案。

強烈建議您設定快訊，監控配額用量和限制。此外，如果流量模式出現尖峰或規律的自然成長，建議考慮將配額超量配置 25% 至 50%，以處理非預期的需求。
CreateWriteStream 要求 每小時 10,000 個串流，每個專案每個區域 每個專案每個區域每小時最多可發出 10,000 次呼叫。CreateWriteStream如果您不需要僅一次語意，請考慮使用預設串流。這項配額是以小時為單位，但 Google Cloud 控制台顯示的指標是以分鐘為單位。
待處理的串流位元組數 多區域 10 TB；區域 1 TB 每次觸發提交作業時，您最多可以在 us 和 eu 多區域提交 10 TB 的資料，在其他區域則為 1 TB。這項配額沒有配額報表。

Storage Write API (gRPC) 要求有下列限制：

限制 預設 附註
批次提交 每個資料表 10,000 個串流 您可以在每次 BatchCommitWriteStream 呼叫中提交最多 10,000 個串流。
AppendRows 要求大小 20 MB 要求大小上限為 20 MB。

串流資料插入

使用 BigQuery Storage Write API (REST) 將資料串流至 BigQuery 時，適用下列配額和限制。如要瞭解如何採取策略，確保不超過這些限制，請參閱「排解配額錯誤」。如果超出這些配額，BigQuery 會傳回 quotaExceeded 錯誤。如果配額使用率在一年以上都明顯偏低，BigQuery 可能會調降配額。

限制 預設 附註
專案在 us 和 eu 多重區域的每秒位元組數上限 每秒 1 GB

專案每秒最多可串流 1 GB 的資料。這項配額在特定多區域內是累計計算。換句話說，在多區域中，特定專案串流至所有資料表的位元組總和，每秒不得超過 1 GB。

超過這個限制會導致 quotaExceeded 錯誤。

如有需要，請與 Cloud Customer Care 聯絡，要求提高配額。請盡早提出增加額度的要求，最晚須在需要額度前兩週提出。配額增加需要一段時間才會生效，尤其是大幅增加配額時。
所有其他位置的每個專案每秒位元組數上限 每秒 300 MB

在 us 和 eu 多區域以外的所有位置，專案每秒最多可串流 300 MB。這項配額會在指定的多區域內累計。換句話說，特定專案在某個區域中，串流至所有資料表的每秒位元組總和不得超過 300 MB。

超過這個限制會導致 quotaExceeded 錯誤。

如有需要，請與 Cloud Customer Care 聯絡，要求提高配額。請盡早提出增加額度的要求，最晚須在需要額度前兩週提出。配額增加需要一段時間才會生效，尤其是大幅增加配額時。
資料列大小上限 10 MB 如果超過這個值，就會導致 invalid 錯誤。
HTTP 要求大小限制 10 MB

如果超過這個值，就會導致 invalid 錯誤。

要求會在內部從 HTTP JSON 轉換為內部資料結構。翻譯後的資料結構有自己的強制大小限制。很難預測產生的內部資料結構大小，但如果將 HTTP 要求保持在 10 MB 以下，觸及內部限制的機率很低。
每個要求的列數上限 50,000 列 建議上限為 500 個資料列。批次處理可提高效能和輸送量，但會增加每個要求的延遲時間。如果每個要求傳送的資料列太少，每個要求的額外負荷可能會導致擷取作業效率不彰。每項要求包含的資料列過多，導致處理量下降。使用具代表性的資料 (結構定義和資料大小) 進行實驗，找出資料的理想批量。
insertId 欄位長度 128 個半形字元 如果超過這個值，就會導致 invalid 錯誤。

如需額外串流配額，請參閱「申請提高配額」。

頻寬

下列配額適用於複製頻寬：

配額 預設 附註
每個區域的初始補充作業複製頻寬上限，這些區域的資料會從主要副本跨區域輸出至次要副本。 每個機構每個區域 10 個實體 GiBps
每個區域的持續複製頻寬上限，這些區域的資料會從主要副本跨區域輸出至次要副本。 每個機構每個區域 5 個實體 GiBps
每個區域的強化型複製頻寬上限，這些區域的資料會從主要副本跨區域輸出至次要副本。 每個機構每個區域 5 個實體 GiBps 強化型複製功能的頻寬配額不適用於初始回填作業。

如果專案的複製頻寬超過特定配額，受影響專案的複製作業可能會停止，並顯示 rateLimitExceeded 錯誤，其中包含超出配額的詳細資料。