配額與限制
本文列出 BigQuery 適用的配額和系統限制。
- 配額會指定您可使用的可計數共用資源數量。配額是由 BigQuery 等 Google Cloud 服務定義。
- 系統限制是無法變更的固定值。
Google Cloud 會使用配額來確保公平性，並減少資源使用量和可用性暴增的情況。配額會限制專案可使用的Google Cloud 資源 Google Cloud 數量。配額適用於各種資源類型，包括硬體、軟體和網路元件。舉例來說，配額可以限制對服務發出的 API 呼叫數、專案並行使用的負載平衡器數量，或是可建立的專案數量。配額可以預防服務過載，進而保障Google Cloud 使用者社群的權益。配額也能協助您管理自己的 Google Cloud 資源。
Cloud Quotas 系統會執行下列操作：
在大多數情況下，如果您嘗試使用的資源超過配額，系統會封鎖資源存取權，導致您嘗試執行的工作失敗。
配額通常是在 Google Cloud 專案 層級套用。在一個專案中使用資源，不會影響另一個專案的可用配額。在 Google Cloud 專案中，所有應用程式和 IP 位址會共用配額。
BigQuery 資源也有系統限制。 系統限制無法變更。
根據預設，BigQuery 配額和限制會以每個專案為單位套用。如果配額和限制適用於不同基準，系統會標示出來，例如每個資料表的欄數上限，或是每位使用者的並行 API 要求數上限。 具體規定會因資源供應狀況、使用情況、服務使用記錄和其他因素而有不同，並隨時可能變更，恕不另行通知。
配額補充
在一天當中，系統會定時為您補充每日配額，以便達到控管頻率限制行為的目標。另外，系統也會間歇性重新整理，以免在配額耗盡時發生服務長時間中斷的狀況。一般來說，系統在幾分鐘內即可提供更多配額，並非一天僅全面補充一次。
申請提高配額
如要調整大部分配額，請使用 Google Cloud 控制台。 詳情請參閱「要求調整配額」。
如需在 Google Cloud 控制台中申請提高配額的逐步指南，請按一下「Guide me」(逐步引導)：
設定配額用量上限
如要瞭解如何建立配額覆寫，藉此限制特定資源的用量，請參閱建立配額覆寫。
所需權限
如要在Google Cloud 控制台中查看及更新 BigQuery 配額，您需要與任何 Google Cloud配額相同的權限。詳情請參閱Google Cloud 配額權限。
疑難排解
如要瞭解如何排解配額和限制相關錯誤，請參閱「排解 BigQuery 配額錯誤」。
工作
無論是使用 Google Cloud 主控台、bq 指令列工具，還是透過程式使用 REST API 或用戶端程式庫，BigQuery 代表您執行的工作都會受到配額和限制規範。
查詢工作
以下配額適用於您在執行互動式查詢、排程查詢時自動建立的查詢工作，以及使用 jobs.query 和查詢類型 jobs.insert API 方法提交的工作：
| 配額 | 預設 | 附註 |
|---|---|---|
| 每日查詢用量 | 無限制 | 專案中的查詢可處理的位元組數沒有上限。 在 Google Cloud 主控台中查看配額 |
| 每位使用者每天的查詢用量 | 無限制 | 使用者每天可處理的查詢位元組數沒有限制。 在 Google Cloud 主控台中查看配額 |
| Cloud SQL 聯合式查詢跨區域位元組數 (每日) | 1 TB | 如果
BigQuery 查詢處理位置和 Cloud SQL 執行個體位置不同，就會視為跨區域查詢。專案每日可執行高達 1 TB 的跨地區查詢。請參閱 Cloud SQL 聯合查詢。 在 Google Cloud 主控台中查看配額 |
| 每日跨雲端傳輸的位元組數 | 1 TB |
您每天最多可從 Amazon S3 值區或 Azure Blob 儲存體轉移 1 TB 的資料。詳情請參閱從 Amazon S3 和 Azure 進行跨雲端轉移。 在 Google Cloud 主控台中查看配額 |
以下限制適用於您在執行互動式查詢、排程查詢時自動建立的查詢工作，以及使用 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 小時，然後就會失敗。不過，有時系統會重新嘗試執行查詢。每項查詢最多可嘗試執行三次，每次嘗試最多可執行 6 小時。因此，查詢的總執行時間可能會超過 6 小時。
|
| 每個查詢參照的資源數量上限 | 1,000 項資源 |
完全展開後，查詢最多可參照 1,000 個不重複的資料表、不重複的檢視區塊、不重複的
使用者定義函式 (UDF) 和不重複的資料表函式。這項限制包括：
|
| SQL 查詢字元長度上限 | 1,024k 個字元 |
SQL 查詢的長度上限為 1,024,000 個字元。這項限制包含註解和空白字元。如果查詢較長，您會收到下列錯誤訊息：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 錯誤。
詳情請參閱
billingTierLimitExceeded。
|
| 多陳述式交易資料表突變 | 100 個表格 | 交易最多可變動 100 個資料表中的資料。 |
| 多陳述式交易分割區修改 | 100,000 次分區修改 | 一筆 交易最多可執行 100,000 次分區修改作業。 |
| BigQuery Omni 查詢結果大小上限 | 20 GiB 未壓縮 | 查詢 Azure 或 AWS 資料時，結果大小上限為 20 GiB 邏輯位元組。如果查詢結果大於 20 GiB，建議將結果匯出至 Amazon S3 或 Blob Storage。 詳情請參閱 BigQuery Omni 限制。 |
| BigQuery Omni 每日查詢結果總大小 | 1 TB | 專案的查詢結果大小總計為每日 1 TB。
詳情請參閱 BigQuery Omni 限制。 |
| BigQuery Omni 的最大資料列大小 | 10 MiB | 查詢 Azure 或 AWS 資料時，資料列大小上限為 10 MiB。詳情請參閱 BigQuery Omni 限制。 |
雖然已排定的查詢會使用 BigQuery 資料移轉服務功能，但這類查詢並非移轉作業，也不受載入工作限制的限制。
匯出工作
以下限制適用於使用 bq 指令列工具、 Google Cloud 主控台或匯出類型 jobs.insert API 方法，從 BigQuery 匯出資料的工作。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每日匯出位元組數上限 | 50 TiB |
使用共用運算單元集區，即可每日從專案匯出最高 50 TiB(太位元組) 的資料，無須支付費用。您可以設定 Cloud Monitoring 快訊政策，在匯出位元組數達到指定門檻時收到通知。如要每天匯出超過 50 TiB(太位元組) 的資料，請執行下列其中一項操作：
|
| 每天的匯出工作數上限 | 100,000 次匯出 |
每個專案每天最多可執行 100,000 次匯出作業。
如要每天執行超過 10 萬次匯出作業，請採取下列其中一項做法：
|
| 匯出至單一檔案的資料表大小上限 | 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 值區中的檔案數量上限 | 大約 6,000 萬個檔案 | 載入工作可從最多約 6,000 萬個檔案的 Cloud Storage 值區讀取資料。 |
| 載入工作執行時間限制 | 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 控制台 查看配額 |
下列地區的運算單元總數：
|
2,000 個運算單元 |
您可以使用 Google Cloud 控制台，在每個列出的區域中購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台 查看配額 |
下列地區的總運算單元數：
|
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 個預留項目 | 機構中每個管理專案在特定位置 / 區域的標準版預留項目數量上限。 |
| Enterprise 或 Enterprise Plus 版預留項目數量上限 | 每項專案 200 個預留項目 | 機構中每個管理專案在特定位置 / 區域的 Enterprise 或 Enterprise Plus 版本預留項目數量上限。 |
與 CONTINUOUS 工作類型預留項目指派相關聯的預留項目運算單元數量上限。 |
500 個運算單元 |
如要建立工作類型為 CONTINUOUS 的保留項目指派作業，相關聯的保留項目不得超過 500 個時段。 |
資料集
以下限制適用於 BigQuery資料集：
| 限制 | 預設 | 附註 |
|---|---|---|
| 資料集數量上限 | 無限制 | 專案可擁有的資料集數量沒有限制。 |
| 每個資料集的資料表數量 | 無限制 | 如使用 API 呼叫，當資料集中的資料表數接近 50,000 個時，列舉效能會下降。 Google Cloud 控制台最多可為每個資料集顯示 50,000 個資料表。 |
| 資料集存取控制清單中的授權資源數量 | 2,500 項資源 | 資料集的存取控制清單最多可有 2,500 個授權資源，包括授權檢視表、授權資料集和授權函式。如果授權檢視區塊數量過多，導致超出上限，建議將檢視區塊分組到授權資料集中。 |
| 每個資料集每 10 秒的資料集更新作業數 | 5 項作業 |
專案每 10 秒最多可執行五項資料集更新作業。
資料集更新限制適用於下列項目執行的所有中繼資料更新作業：
|
| 資料集說明的長度上限 | 16,384 個半形字元 | 為資料集新增說明文字時，最多可以輸入 16,384 個字元。 |
資料表
所有資料表
以下限制適用於所有 BigQuery 資料表。
| 限制 | 預設 | 附註 |
|---|---|---|
| 欄名稱長度上限 | 300 個字元 | 欄名長度上限為 300 個字元。 |
| 資料欄說明的長度上限 | 1,024 個字元 | 您在資料欄中新增說明時，最多可以輸入 1,024 個字元。 |
| 巢狀記錄的深度上限 | 15 個等級 |
RECORD 類型的資料欄可以包含巢狀RECORD 型別，也稱為子項記錄。巢狀結構深度上限為 15 層。
這項限制與記錄是否為純量或陣列形式 (重複) 無關。 |
| 資料表說明的長度上限 | 16,384 個半形字元 | 為表格新增說明文字時，最多可以輸入 16,384 個字元。 |
標準資料表
以下限制適用於 BigQuery 標準 (內建) 資料表：
| 限制 | 預設 | 附註 |
|---|---|---|
| 每日資料表修改次數 | 1,500 項修改 | 不論修改作業是更新資料表中繼資料、附加或更新資料，還是截斷資料表，每個專案每天最多可修改每個資料表 1,500 次。這項限制無法變更，且包含下列所有工作：載入工作、複製工作和 查詢工作，這些工作會將資料附加至目的地資料表或覆寫目的地資料表。 DML 陳述式「不會」計入每日資料表修改次數。 串流資料不會計入每日資料表修改次數。 |
| 每個資料表的資料表中繼資料更新作業頻率上限 | 每 10 秒 5 項作業 |
每個資料表每 10 秒最多可進行五項資料表中繼資料更新作業。這項限制適用於下列項目執行的所有資料表中繼資料更新作業：
DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 陳述式將資料寫入資料表。請注意，雖然 DML 陳述式會計入這項配額，但即使達到配額上限，也不會受到限制。DML 作業有專屬的速率限制。
如果超過這項限制，系統會顯示類似
|
| 每個資料表的欄數上限 | 10,000 欄 | 每個資料表、查詢結果或檢視表定義最多可有 10,000 個資料欄。包括巢狀和重複資料欄。 |
外部資料表
以下限制適用於以 Parquet、ORC、Avro、CSV 或 JSON 格式將資料儲存在 Cloud Storage 的 BigQuery 資料表：
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個外部資料表的來源 URI 數量上限 | 10,000 個 URI | 每個外部資料表最多可有 10,000 個來源 URI。 |
| 每個外部資料表的檔案數量上限 | 10,000,000 個檔案 | 外部資料表最多可有 1000 萬個檔案，與任何萬用字元 URI 相符的所有檔案都會計入限制額度。 |
| 每個外部資料表在 Cloud Storage 中儲存資料的大小上限 | 600 TB | 外部資料表在所有輸入檔案中最多可有 600 TB。這項限制適用於儲存在 Cloud Storage 的檔案大小；這個大小不同於查詢定價公式使用的大小。如果是外部分區資料表，這項限制會在 分區修剪後套用。 |
| 來源 Cloud Storage 值區中的檔案數量上限 | 大約 6,000 萬個檔案 | 外部資料表最多可參照包含約 6,000 萬個檔案的 Cloud Storage 值區。如果是外部分區資料表，這項限制會在 分區修剪前套用。 |
分區資料表
以下限制適用於 BigQuery 已分割資料表。
分區限制適用於下列所有載入工作、複製工作和查詢工作：將資料附加至目的地分區或覆寫目的地分區。
單一工作可能會影響多個分區。舉例來說，查詢工作和載入工作可以寫入多個分區。
BigQuery 會透過受工作影響的分區數量來判斷工作占用的限制。不過，串流資料插入並不會影響這項限制。
如要瞭解如何採取策略，確保分割資料表不超出限制，請參閱「 排解配額錯誤」。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個分區資料表的分區數量 | 10,000 個分割區 | 每個已分割的資料表最多可有 10,000 個分區。如果超過這個限制，建議您除了分區外，也考慮使用 分群，或改用分群。 |
| 單一工作修改的分區數量 | 4,000 個分區 | 每個工作作業 (查詢或載入作業) 最多可影響 4,000 個分區。 BigQuery 會拒絕嘗試修改超過 4,000 個分區的任何查詢或載入工作。 |
| 每個分區資料表每天在擷取時間內可修改分區的次數 | 11,000 項修改 |
專案每天最多可進行 11,000 次分割區修改。 修改分區是指在分區資料表中附加、更新、刪除或截斷資料。每種資料修改都會計為一次分割區修改。舉例來說，刪除一個資料列會計為一次分區修改，刪除整個分區也會計為一次修改。如果您從一個分區刪除資料列，然後插入另一個分區，這會計為兩次分區修改。 使用 DML 陳述式或串流 API 進行的修改，不會計入每日分區修改次數。 |
| 每個依資料欄分區的資料表每日可修改分區的次數 | 30,000 項修改 | 您的專案每天最多可對資料欄分區資料表進行 30,000 次分區修改。 DML 陳述式不會計入每日分區修改次數。 串流資料不會計入每日分區修改次數。 |
| 每個分區資料表的資料表中繼資料更新作業頻率上限 | 每 10 秒 50 次修改 |
每個分區資料表每 10 秒最多可進行 50 次修改。這項限制適用於所有分區資料表中繼資料更新作業，包括下列作業：
DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 陳述式將資料寫入資料表。
如果超過這項限制，系統會顯示類似
如要找出計入這項限制的作業，請 檢查記錄。 |
| 範圍分區的可能範圍數量 | 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,000 個字元。這項限制適用於單一查詢，不包含查詢中參照的檢視區塊長度。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」。 | |
| 檢視畫面說明的長度上限 | 16,384 個半形字元 | 為檢視區塊新增說明文字時，最多可以輸入 16,384 個字元。 |
具體化檢視表
以下限制適用於 BigQuery 具體化檢視區塊：
| 限制 | 預設 | 附註 |
|---|---|---|
| 基底資料表參照 (相同資料集) | 20 個具體化檢視表 | 每個基礎資料表最多可由同一資料集的 20 個具體化檢視區塊參照。 |
| 基底資料表參照 (相同專案) | 100 個具體化檢視表 | 每個基礎資料表最多可供同一專案的 100 個具體化檢視區塊參照。 |
| 基底資料表參照 (整個機構) | 500 個具體化檢視表 | 整個機構最多可從每個基本資料表參照 500 個具體化檢視區塊。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」。 | |
| 具體化檢視表說明的長度上限 | 16,384 個半形字元 | 為具體化檢視表新增說明文字時，最多可以輸入 16,384 個字元。 |
搜尋索引
以下限制適用於 BigQuery 搜尋索引：
| 限制 | 預設 | 附註 |
|---|---|---|
每個專案每天在每個區域的 CREATE INDEX DDL 陳述式數量 |
500 項作業 |
每個專案每天在一個區域內最多可發出 500 次 CREATE INDEX DDL 作業。
|
| 每天每個資料表的搜尋索引 DDL 陳述式數量 | 20 項作業 |
每個專案每天最多可對每個資料表發出 20 個 CREATE 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 列 |
表格最多可有 10,000,000,000 列，用於建立IVF向量索引 |
索引類型 TREE_AH 的基本資料表列數上限
|
200,000,000 列 |
資料表最多可有 200,000,000 列，以建立TREE_AH向量索引 |
分區索引類型的基本資料表列數上限
TREE_AH |
總共 10,000,000,000 列 每個分區 200,000,000 列 |
資料表最多可有 10,000,000,000 個資料列，每個分區最多可有 200,000,000 個資料列，以建立TREE_AH分區向量索引。
|
| 已建立索引的資料欄中陣列的大小上限 | 1,600 個元素 | 建立索引的資料欄陣列最多可有 1,600 個元素。 |
| 向量索引母體的資料表大小下限 | 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 查詢中暫時性和永久的 使用者定義函式 (UDF)。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每列輸出內容的上限 | 5 MB | 處理單一資料列時，JavaScript UDF 輸出的資料量上限約為 5 MB。 |
| 使用 JavaScript UDF 時，舊版 SQL 查詢的並行上限 | 6 項查詢 | 您的專案最多可有六個並行舊版 SQL 查詢，其中包含 JavaScript 中的 UDF。這項限制同時適用於互動式查詢和批次查詢。這項限制不適用於 GoogleSQL 查詢。 |
| 每個查詢的 JavaScript UDF 資源數量上限 | 50 項資源 | 查詢工作最多可以有 50 個 JavaScript UDF 資源，例如內嵌程式碼 blob 或外部檔案。 |
| 內嵌程式碼 blob 大小上限 | 32 KB | UDF 中的內嵌程式碼 blob 大小上限為 32 KB。 |
| 每項外部程式碼資源的大小上限 | 1 MB | 每項 JavaScript 程式碼資源的大小上限為 1 MB。 |
永久性 UDF 適用下列限制：
| 限制 | 預設 | 附註 |
|---|---|---|
| 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 個字元。 |
| 每個 UDF 每 10 秒的更新頻率上限 | 5 則更新 | 專案每 10 秒最多可更新 UDF 五次。 |
| 每個資料集的授權 UDF 數量上限 | 請參閱「資料集」。 |
遠端函式
以下限制適用於 BigQuery 中的遠端函式。
| 限制 | 預設 | 附註 |
|---|---|---|
| 包含遠端函式的並行查詢數量上限 | 10 項查詢 | 每個專案最多可使用 遠端函式執行十個並行查詢。 |
| 輸入內容大小上限 | 5 MB | 單一資料列中所有輸入引數的總大小上限為 5 MB。 |
| HTTP 回應大小上限 (第 1 代 Cloud Run 函式) | 10 MB | Cloud Run 函式第 1 代的 HTTP 回應內文最多為 10 MB。如果超過這個值，查詢就會失敗。 |
| HTTP 回應大小限制 (Cloud Run 函式第 2 代或 Cloud Run) | 15 MB | Cloud Run 函式第 2 代或 Cloud Run 的 HTTP 回應主體最多為 15 MB。如果超過這個值，查詢就會失敗。 |
| HTTP 叫用時間上限 (Cloud Run 函式第 1 代) | 9 分鐘 | 您可以為第 1 代 Cloud Run 函式設定個別 HTTP 叫用的時間限制，但時間限制上限為 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，但下列地點除外：
在這些地區，每個專案每個地區最多可使用 500 個 CPU。 如果您在多區域位置和同一地理區域的單一區域位置中執行並行查詢，查詢可能會耗用相同的並行 CPU 配額。 |
| 使用中標準永久磁碟的總大小上限 | 204.8 TB | 每個專案的每個位置最多可使用 204.8 TB 的標準永久磁碟。已處理的查詢不會計入這項限制。 如果您在多區域位置和同一地理區域的單一區域位置中執行並行查詢，查詢可能會耗用相同的標準永久磁碟配額。 |
筆記本
所有 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 將資料串流至資料表。
|
| 每個資料表的並行變動 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 小時後逾時。 |
Vertex AI 和 Cloud AI 服務函式
下列限制適用於使用 Vertex AI 大型語言模型 (LLM) 和 Cloud AI 服務的函式：
1 這項服務會使用動態權杖型批次處理，盡可能將多個資料列放入一個要求中。實際效能會因嵌入內容長度而異。如要提高每個工作可處理的資料列數上限，請申請調整 QPM 配額。
對 Gemini 2.0 以上版本模型執行 BigQuery ML 函式時，系統會使用動態共用配額 (DSQ)，因此配額會因資源可用性而異。
對於支援的 Gemini 模型，您可以搭配使用 Vertex AI 佈建處理量與 ML.GENERATE_TEXT 和 AI.GENERATE 函式，為要求提供一致的高處理量。
如要進一步瞭解 Vertex AI LLM 和 Cloud AI 服務 API 的配額，請參閱下列文件：
- Vertex AI 生成式 AI 配額限制
- Cloud Translation API 配額與限制
- Vision API 配額與限制
- Natural Language API 配額和限制
- Document AI 配額和限制
- Speech-to-Text 配額與限制
每項工作的資料列配額代表系統在 6 小時內可處理的理論資料列數上限。實際處理的資料列數取決於許多其他因素，包括輸入大小和網路狀況。舉例來說，ML.TRANSCRIBE 可以處理的短音訊比長音訊多。
如要為 BigQuery ML 函式要求更多配額，請先調整相關聯的 Vertex AI LLM 或 Cloud AI 服務配額，然後傳送電子郵件至 bqml-feedback@google.com，並附上調整後的 LLM 或 Cloud AI 服務配額資訊。如要進一步瞭解如何要求提高這些服務的配額，請參閱「要求調整配額」。
配額定義
以下列出適用於 Vertex AI 和 Cloud AI 服務函式的配額：
- 呼叫 Vertex AI 基礎模型的函式會使用一項 Vertex AI 配額，也就是每分鐘查詢次數 (QPM)。在此脈絡中，查詢是指函式對 Vertex AI 模型 API 的要求呼叫。QPM 配額適用於基礎模型，以及該模型的所有版本、ID 和微調版本。如要進一步瞭解 Vertex AI 基礎模型配額，請參閱「各區域和模型的配額」。
- 呼叫 Cloud AI 服務的函式會使用目標服務的要求配額。詳情請參閱指定 Cloud AI 服務的配額參考資料。
BigQuery ML 使用三種配額：
每分鐘要求數。這項配額是指函式每分鐘可對 Vertex AI 模型或 Cloud AI 服務的 API 提出的要求呼叫次數上限。這項限制適用於每個專案。
如果是呼叫 Vertex AI 基礎模型的函式，每分鐘的要求呼叫次數會因 Vertex AI 模型端點、版本和區域而異。這個配額在概念上與 Vertex AI 使用的 QPM 配額相同，但值可能小於對應模型的 QPM 配額。
每個職缺的列數。這項配額是每個查詢作業允許的列數上限。
並行執行的工作數量。這項配額是每個專案的限制，規定指定函式可同時執行的 SQL 查詢數量。
以下範例說明如何解讀一般情況下的配額限制：
我在 Vertex AI 中的配額為 1,000 QPM，因此含有 100,000 個資料列的查詢應需要約 100 分鐘。為什麼工作執行時間較長？
即使輸入資料相同，工作執行時間也可能有所不同。在 Vertex AI 中，遠端程序呼叫 (RPC) 的優先順序各不相同，可避免配額耗盡。配額不足時，優先順序較低的 RPC 會等待，如果處理時間過長，可能會失敗。
如何解讀每個工作配額的資料列？
在 BigQuery 中，查詢最多可執行六小時。支援的資料列上限取決於這條時間軸和 Vertex AI QPM 配額，確保 BigQuery 可以在六小時內完成查詢處理作業。由於查詢通常無法用盡配額，因此這個數字會低於 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 每分鐘請求配額和 Vertex AI QPM 配額。如果有多個查詢都符合每個工作的資料列配額和並行執行工作數配額，累積處理量就會用盡每分鐘要求配額。
BI Engine
以下限制適用於 BigQuery BI Engine。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個專案/每個位置的保留項目大小上限 (BigQuery BI Engine) | 250 GiB | 每個專案/每個位置的預設保留項目大小上限為 250 GiB。 您可以 要求提高專案的預留容量上限。大多數地區都可增加預訂量，處理時間可能需要 3 個工作天到一週。 |
| 每個查詢的資料列數量上限 | 70 億 | 每個查詢的資料列數量上限。 |
BigQuery sharing (舊稱 Analytics Hub)
以下限制適用於 BigQuery sharing (舊稱 Analytics Hub)：
| 限制 | 預設 | 附註 |
|---|---|---|
| 每項專案的資料交換數上限 | 500 次交換 | 每個專案最多可建立 500 個資料交換。 |
| 每個資料交換的商家資訊數量上限 | 1,000 筆房源資訊 | 資料交換最多可建立 1,000 個商家資訊。 |
| 每個共用資料集的連結資料集數量上限 | 1,000 個連結的資料集 | 所有 BigQuery 共用訂閱者加總，每個共用資料集最多可有 1,000 個連結的資料集。 |
Dataplex Universal Catalog 自動探索功能
下列限制適用於 Dataplex Universal Catalog 自動探索功能：
| 限制 | 預設 | 附註 |
|---|---|---|
| 探索掃描支援的每個 Cloud Storage 值區，最多可有 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 的資料表列資料。這項配額適用於系統正在讀取的資料表所屬的專案。包含
jobs.getQueryResults 與會透過
jobs.query 和
jobs.insert 擷取結果的其他 API 也會耗用這項配額。在 Google Cloud 主控台 中查看配額
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 項要求 |
專案每秒最多可提出兩項 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 個連線 | 您的專案每分鐘最多可在 AWS 和 Azure 建立 10 個 BigQuery Omni 連線。 |
| 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 | 您輸入的互動式 SQL 翻譯字串不得超過 1 MB。使用 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 Service List 要求數 每位使用者每分鐘的 EDWMigration 服務清單要求數 |
12,000 項要求 2,500 項要求 |
您的專案每分鐘最多可以提出 12,000 次 Migration API List 要求。 每位使用者每分鐘最多可提出 2,500 個 Migration API List 要求。 在 Google Cloud 控制台中查看配額 |
|
每分鐘 EDWMigration 服務 Get 要求數 每位使用者每分鐘的 EDWMigration Service Get 要求數 |
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
| 限制 | 預設 | 附註 |
|---|---|---|
通話次數上限為
dataPolicies.list
次。
|
每項專案每分鐘 400 項要求 每個機構每分鐘 600 項要求 |
|
dataPolicies.testIamPermissions 呼叫次數上限。
|
每項專案每分鐘 400 項要求 每個機構每分鐘 600 項要求 |
|
| 讀取要求數量上限。 |
每項專案每分鐘 1,200 個要求 每個機構每分鐘 1,800 個要求 |
這包括對
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 個要求 | 您的多區域專案每分鐘最多可提出 200 個要求。 在 Google Cloud 控制台中查看配額 |
Storage Read API
以下配額適用於 BigQuery Storage Read API 要求：
| 配額 | 預設 | 附註 |
|---|---|---|
| 每位使用者每分鐘的讀取資料平面要求數 | 25,000 項要求 |
每位使用者每分鐘最多可發出 25,000 個 ReadRows 呼叫，每個專案皆適用此限制。在 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。 |
| 並行連線數上限 | 多區域 2,000 個；區域 400 個 |
在 us 和 eu 多地區中，每項專案最多可開啟 2,000 個並行 ReadRows 連線，其他地區則為 400 個並行 ReadRows 連線。在某些情況下，您可能無法達到這個上限，只能建立較少的並行連線。
|
| 每個串流的記憶體用量上限 | 1.5 GB | 每個串流的記憶體上限為約略值，因為這項限制是根據資料列資料的內部呈現方式而定。如果單一資料列使用的記憶體超過 1.5 GB，串流可能會失敗。詳情請參閱「排解資源超出限制的問題」。 |
Storage Write API
下列配額適用於 Storage Write API 要求。您可以在資料夾層級套用下列配額。這些配額會經過彙整，並在所有子專案之間共用。如要啟用這項設定，請與 Cloud Customer Care 團隊聯絡。
如果您打算要求調整配額，請在要求中附上配額錯誤訊息，以加快處理速度。
| 配額 | 預設 | 附註 |
|---|---|---|
| 並行連線數量 | 單一區域 1,000 個；多區域 10,000 個 |
並行連線配額是根據發起 Storage Write API 要求的用戶端專案而定，而非包含 BigQuery 資料集資源的專案。起始專案是指與 API 金鑰或服務帳戶相關聯的專案。 您的專案可以在一個區域中處理 1,000 個並行連線，或在 在 Java 或 Go 中使用預設串流時，建議使用Storage Write API 多工，透過共用連線寫入多個目的地資料表，以減少所需的整體連線數。如果您使用 Beam 連接器，且語意為「至少一次」，可以將 UseStorageApiConnectionPool 設為 您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。根據您所在的區域，選取並行連線限制名稱。 |
| 處理量 | 多區域的輸送量為每秒 3 GB；區域的輸送量為每秒 300 MB |
在 us 和 eu 多地區中，每個專案最多可串流 3 GBps，在其他地區則為 300 MBps。在 Google Cloud 主控台 中查看配額 您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。根據您所在的區域選取輸送量限制名稱。 |
CreateWriteStream 要求
|
每項專案每區域每小時 10,000 個串流 |
每項專案在每個區域中，每小時最多可呼叫 CreateWriteStream 10,000 次。如果您不需要「剛好一次」語意，請考慮使用預設串流。這項配額以每小時為單位，但 Google Cloud 控制台顯示的指標以每分鐘為單位。 |
| 待處理的串流位元組數 | 多區域為 10 TB；區域為 1 TB |
每次觸發提交作業時，您最多可以在 us 和 eu 多地區提交 10 TB 的資料，在其他地區則為 1 TB。這項配額沒有配額報表。
|
下列限制適用於 Storage Write API 要求：
| 限制 | 預設 | 附註 |
|---|---|---|
| 批次提交 | 每個資料表 10,000 個串流 |
每次 BatchCommitWriteStream 呼叫最多可提交 10,000 個串流。
|
AppendRows
要求大小
|
10 MB | 要求大小上限為 10 MB。 |
串流資料插入
使用舊版串流 API 將資料串流到 BigQuery 時，適用下列配額和限制。
如要瞭解如何避免超出這些限制，請參閱排解配額錯誤。如果超出配額，系統會傳回 quotaExceeded 錯誤。
| 限制 | 預設 | 附註 |
|---|---|---|
在 us 和 eu 多地區中，每項專案每秒的位元組數上限 |
每秒 1 GB |
專案每秒最多可串流 1 GB 的資料。在指定的多地區中，這項配額會持續累計。換句話說，在多地區中，特定專案每秒串流至所有資料表的位元組總和上限為 1 GB。
如果超出這項限制，系統就會產生 如有需要，請與 Cloud Customer Care 聯絡，申請提高配額。請盡早提出增加額度的要求，最晚要在需要額度前兩週提出。配額增加需要一段時間才會生效，尤其是大幅增加配額時。 |
| 在其他所有位置，每項專案每秒的位元組數上限 | 每秒 300 MB |
在
如果超出這項限制，系統就會產生 如有需要，請與 Cloud Customer Care 聯絡，申請提高配額。請盡早提出增加額度的要求，最晚要在需要額度前兩週提出。配額增加需要一段時間才會生效，尤其是大幅增加配額時。 |
| 資料列大小上限 | 10 MB |
如果超過這個值，系統就會產生 invalid 錯誤。
|
| HTTP 要求大小上限 | 10 MB |
如果超過這個值，系統就會產生 內部會將要求從 HTTP JSON 轉譯為內部資料結構。轉譯的資料結構具有專屬的大小限制。預估產生的內部資料結構大小並非易事，但如果您的 HTTP 要求不超過 10 MB，應該不太會達到內部限制。 |
| 每項要求的資料列數量上限 | 50,000 列 | 建議上限為 500 個資料列。批次處理可以將效能和總處理量提高到一定程度，但每項要求的處理時間皆會有所延遲。如果每項要求的資料列數量過少，要求產生的工作負擔可能會導致擷取作業效率低落。如果每項要求的資料列數量過多，總處理量可能會減少。使用代表性資料 (結構定義和資料大小) 進行實驗，找出資料的理想批次大小。 |
insertId 欄位長度
|
128 個字元 |
如果超過這個值，系統就會產生 invalid 錯誤。
|
如需額外的串流配額，請參閱「要求增加配額」。
頻寬
下列配額適用於複製頻寬：
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域的初始回填複製頻寬上限，這些區域的資料會從主要副本跨區域輸出至次要副本。 | 每個機構在每個區域的實體 GiBps 為 10 | |
| 每個區域的持續複製作業頻寬上限，這些區域的資料會從主要副本跨區域傳輸至次要副本。 | 每個機構在每個區域的實體 GiBps 為 5 | |
| 每個區域的強化型複製頻寬上限，這些區域的資料會從主要副本跨區域輸出至次要副本。 | 每個機構在每個區域的實體 GiBps 為 5 | 強化型複製功能的頻寬配額不適用於初始回填作業。 |
如果專案的複製頻寬超過特定配額，受影響專案的複製作業可能會停止，並顯示 rateLimitExceeded 錯誤，其中包含超過配額的詳細資料。