配額與限制
本文件列出 BigQuery 適用的配額和系統限制。
- 配額會指定您可使用的可計數共用資源數量。配額是由 Google Cloud 服務 (例如 BigQuery) 定義。
- 系統限制為固定值，無法變更。
Google Cloud 會使用配額來確保公平性，並減少資源使用量和可用性的尖峰情形。配額會限制 Google Cloud 專案可使用的Google Cloud 資源數量。配額適用於多種資源類型，包括硬體、軟體和網路元件。舉例來說，配額可以限制向服務發出的 API 呼叫數、專案並行使用的負載平衡器數量，或可建立的專案數量。限制配額可預防服務超載，進而保障Google Cloud 使用者社群的權益。配額也能協助您管理自己的 Google Cloud 資源。
Cloud 配額系統會執行以下作業：
在大多數情況下，如果您嘗試使用的資源超過配額限制，系統會封鎖對該資源的存取權，而您要執行的任務也會失敗。
配額通常會套用至 Google Cloud 專案層級。您在一個專案中使用資源，不會影響其他專案的可用配額。在 Google Cloud 專案中，所有應用程式和 IP 位址都會共用配額。
BigQuery 資源也有系統限制。系統限制無法變更。
根據預設，BigQuery 配額和限制會根據每個專案套用。以不同依據適用的配額和限制會以此方式標示，例如「每個表格」的欄數上限，或「每位使用者」的並行 API 要求數量上限。具體規定會因資源供應狀況、使用者結構、服務使用記錄和其他因素而有不同，並隨時可能變更，恕不另行通知。
配額補充
在一天當中，系統會定時為您補充每日配額，以便達到控管頻率限制行為的目標。另外，系統也會間歇性重新整理，以免在配額耗盡時發生服務長時間中斷的狀況。一般來說，系統在幾分鐘內即可提供更多配額，並非一天僅全面補充一次。
申請提高配額
如要調整大部分配額，請使用 Google Cloud 控制台。詳情請參閱「要求調整配額」。
如要按照逐步指南在 Google Cloud 控制台中申請提高配額，請按一下「Guide me」(逐步引導)：
設定配額用量上限
如要瞭解如何建立配額覆寫值，藉此限制特定資源的用量，請參閱「建立配額覆寫值」。
所需權限
如要在Google Cloud 主控台查看及更新 BigQuery 配額，您需要具備與任何 Google Cloud配額相同的權限。詳情請參閱「Google Cloud 配額權限」。
疑難排解
如要瞭解如何排解與配額和限制相關的錯誤，請參閱「排解 BigQuery 配額錯誤」。
工作
配額和限制適用於 BigQuery 代您執行的工作，無論是透過 Google Cloud 主控台、bq 指令列工具，還是透過程式使用 REST API 或用戶端程式庫，都適用這些限制。
查詢工作
以下配額適用於執行互動式查詢、排定時間查詢時自動建立的查詢工作，以及使用 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 外部資料來源執行十六個並行查詢。 |
| 包含遠端函式的並行查詢數量上限 | 10 個查詢 | 每個專案最多可使用 遠端函式執行十個並行查詢。 |
| 並行多陳述式查詢的數量上限 | 1,000 個多陳述式查詢 | 專案最多可執行 1,000 個多陳述式查詢。如要瞭解與多語句查詢相關的其他配額和限制，請參閱「 多語句查詢」。 |
| 包含使用者定義函式的舊版 SQL 並行查詢數量上限 | 6 個查詢 | 專案最多可同時執行六個舊版 SQL 查詢，並使用使用者定義函式 (UDF)。這項限制同時適用於互動式和批次查詢。包含 UDF 的互動式查詢也會計入互動式查詢的並行限制。不過，這項限制不適用於 GoogleSQL 查詢。 |
| 每日查詢大小限制 | 無限制 | 根據預設，沒有每日查詢量限制。不過，您可以建立自訂配額來控制每日查詢使用量或每位使用者每日查詢使用量，藉此設定使用者可查詢的資料量上限。 |
| ���日目的地資料表更新限制 | 請參閱「每日資料表作業數量上限」。 |
查詢工作中的目的地資料表更新作業，會計入目的地資料表每日作業數量上限。目的地資料表更新包括使用 Google Cloud 主控台、bq 指令列工具或呼叫 jobs.query 和查詢類型 jobs.insert API 方法進行查詢時執行的附加作業和覆寫作業。 |
| 查詢/多個陳述式查詢執行時間限制 | 6 小時 |
查詢或多語句查詢最多可執行 6 小時，然後就會失敗。不過，有時系統會重新嘗試執行查詢。每項查詢最多可嘗試執行三次，每次嘗試最多可執行 6 小時。因此，查詢的總執行時間可能會超過 6 小時。
|
| 每個查詢參照的資源數量上限 | 1,000 項資源 |
查詢在完全展開之後，最多可參照 1,000 個不重複的資料表、檢視表、
使用者定義的函式 (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 錯誤。詳情請參閱「
billingTierLimitExceeded」。 |
| 多陳述式交易表格變異 | 100 個資料表 | 交易最多可變更 100 個表格中的資料。 |
| 多陳述式交易區隔修改 | 100,000 個分區修改 | 交易最多可執行 100,000 次分區修改作業。 |
| BigQuery Omni 的最大查詢結果大小 | 20 GiB (未壓縮) | 查詢 Azure 或 AWS 資料時，結果大小上限為 20 GiB 邏輯位元組。如果查詢結果大於 20 GiB，建議您將結果匯出至 Amazon S3 或 Blob 儲存空間。詳情請參閱「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(Tebibytes) 的資料，無須支付費用。您可以設定 Cloud Monitoring 快訊政策，以便在匯出位元組數量時收到通知。如要每天匯出超過 50 TiB(Tebibytes) 的資料，請執行下列其中一項操作：
|
| 每日匯出工作的數量上限 | 100,000 次匯出 |
您最多可以在專案中執行 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 小時內執行超過 100,000 個負載工作。 |
| 每個資料表的欄數上限 | 10,000 個欄 | 每個資料表最多可包含 10,000 個欄。包括巢狀和重複的資料欄。 |
| 每項載入工作的大小上限 | 15 TB | 所有 CSV、JSON、Avro、Parquet 和 ORC 輸入檔案的總大小可達 15 TB。 |
| 工作設定中的來源 URI 數量上限 | 10,000 個 URI | 工作設定最多可包含 10,000 個來源 URI。 |
| 每項載入工作的檔案數量上限 | 10,000,000 個檔案 | 載入工作最多可包含 1 千萬個檔案，包括與所有萬用字元 URI 相符的所有檔案。 |
| 來源 Cloud Storage 值區中的檔案上限 | 約 60,000,000 個檔案 | 載入工作可從最多約 60,000,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 控制台在 EU 多區域中購買的 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 值區中的檔案上限 | 約 60,000,000 個檔案 | 外部資料表可以參照 Cloud Storage 值區，最多可包含約 60,000,000 個檔案。如果是外部分區資料表，這項限制會在 分區修剪前套用。 |
分區資料表
以下限制適用於 BigQuery 分割資料表。
分區限制適用於將資料附加至或覆寫目的地分區的所有載入工作、複製工作和查詢工作的總和。
單一工作可能會影響多個分區。舉例來說，查詢工作和載入工作可以寫入多個分區。
BigQuery 會透過受工作影響的分區數量來判斷工作占用的配額。不過，串流資料插入並不會影響這項限制。
如要瞭解如何在分割表格限制範圍內，請參閱 排解配額錯誤。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個分區資料表的分區數量 | 10,000 個分區 | 每個分割表格最多可有 10,000 個分割區。如果您超過這個限制，除了使用分區功能外，不妨考慮使用 分群功能，或改用分群功能。 |
| 單一工作可修改的分區數量 | 4,000 個分區 | 每個工作作業 (查詢或載入作業) 最多可影響 4,000 個分區。BigQuery 會������任何嘗試修改超過 4,000 個分區的查詢或載入工作。 |
| 每個分區資料表在擷取時間內每日可修改分區的次數 | 11,000 個修改 | 無論修改內容是附加資料、更新資料，還是截斷擷取時間分區資料表，專案每天最多可進行 11,000 次分區修改。 DML 陳述式「不會」計入每日分區修改次數。 |
| 每個資料欄分區資料表每日可修改分區的次數 | 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 K 個字元。這項限制適用於單一查詢，且不包含查詢中參照的檢視項目長度。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」一文。 | |
| 觀看說明的長度上限 | 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。使用 COLUMN 精細程度建立索引的資料欄，會計入這項限制。default_index_column_granularity以 GLOBAL 細目索引的資料欄數量沒有限制。詳情請參閱「以資料欄精細度建立索引」。 |
向量索引
以下限制適用於 BigQuery 向量索引：
| 限制 | 預設 | 附註 |
|---|---|---|
| 基本資料表的資料列數量下限 | 5,000 列 | 表格必須至少有 5,000 列，才能建立向量索引。 |
| 基礎資料表的資料列數量上限 |
索引類型 IVF的資料列上限為 10,000,000,000 列 索引類型 TREE_AH 的資料列上限為 200,000,000 列
|
建立 IVF 向量索引時，表格最多可包含 10,000,000,000 列，建立 TREE_AH 向量索引時則最多可包含 200,000,000 列。 |
| 已編入索引的資料欄中陣列的大小上限 | 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 名稱長度上限 | 256 個半形字元 | UDF 名稱長度上限為 256 個半形字元。 |
| 引數數量上限 | 256 個引數 | UDF 最多可包含 256 個引數。 |
| 引數名稱的長度上限 | 128 個半形字元 | UDF 引數名稱的長度上限為 128 個半形字元。 |
| UDF 參考鏈深度上限 | 16 個參考資料 | UDF 參照鏈的參照深度上限為 16 個。 |
STRUCT 類型引數或輸出內容的深度上限 |
15 個層級 |
STRUCT 類型 UDF 引數或輸出內容的深度上限為 15 層。 |
每個 UDF 的 STRUCT 類型引數或輸出內容中的欄位數量上限 |
1,024 個欄位 |
在 STRUCT 類型引數和輸出內容中，UDF 最多可包含 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 回應大小上限 (Cloud Run 函式第 1 代) | 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 分鐘 | 您可以為個別 HTTP 叫用設定 Cloud Run 函式第 1 代別的時間限制，但時間限制上限為 9 分鐘。如果超過為 Cloud Run 函式第 1 代設定的時間限制，可能會導致 HTTP 叫用失敗和查詢失敗。 |
| HTTP 叫用時間限制 (Cloud Run 函式第 2 代或 Cloud Run) | 20 分鐘 | 個別 HTTP 對 Cloud Run 函式第 2 代或 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 |
記事本的大小是其內容、中繼資料和編碼額外用量的總和。 如要查看筆記本內容的大小，請展開筆記本標題，然後依序點選「View」和「Notebook info」。 |
| 每秒對 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 個列存取政策。 |
| 每個查詢的資料列存取政策數量上限 | 6,000 項政策 | 查詢最多可存取 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
job 逾時期限預設為 24 小時，但時間序列、AutoML 和超參數調整工作則為 48 小時。 |
Vertex AI 和 Cloud AI 服務函式
下列限制適用於使用 Vertex AI 大型語言模型 (LLM) 和 Cloud AI 服務的函式：
| 功能 | 每分鐘要求數 | 每個工作列數 | 同時執行的工作數量 |
|---|---|---|---|
使用遠端模型時，請使用
ML.GENERATE_TEXT 或
AI.GENERATE_TABLE gemini-1.5-pro 模型 |
60 | 21,600 | 5 |
使用遠端模型時，請使用
ML.GENERATE_TEXT 或
AI.GENERATE_TABLE gemini-1.5-flash 模型 |
200 | 72,000 | 5 |
ML.GENERATE_TEXT 使用遠端模型時，會使用 Anthropic Claude 模型 |
請參閱 Vertex AI 配額頁面 | 每分鐘要求數值 * 60 * 6 | 5 |
ML.GENERATE_TEXT 使用遠端模型時，且該模型為 Llama 3.1 模型 |
60 | 21,600 | 5 |
ML.GENERATE_TEXT 使用遠端模型時，使用 Llama 3.2 或 3.3 模型 |
30 | 10,800 | 5 |
ML.GENERATE_TEXT 使用 Mistral AI 模型的遠端模型 |
60 | 21,600 | 5 |
ML.GENERATE_EMBEDDING 在支援的歐洲單一區域使用 Vertex AI multimodalembedding 模型時，透過遠端模型 |
120 | 14,000 | 5 |
ML.GENERATE_EMBEDDING 與 Vertex AI multimodalembedding 模型搭配使用時，適用於 支援的歐洲單一區域以外的區域 |
600 | 25,000 | 5 |
ML.GENERATE_EMBEDDING 與 us-central1 區域中 Vertex AI text-embedding 和 text-multilingual-embedding 模型的遠端模型搭配使用時 |
1,500 | 30,000,0001 | 5 |
ML.GENERATE_EMBEDDING 與 Vertex AI text-embedding 和 text-multilingual-embedding 模型搭配使用時，在 us-central1 以外的區域中使用遠端模型 |
100 | 2,000,000 | 5 |
ML.PROCESS_DOCUMENT 文件平均一頁 |
600 | 150,000 | 5 |
ML.PROCESS_DOCUMENT 文件平均有十頁 |
600 | 100,000 | 5 |
ML.PROCESS_DOCUMENT 文件平均有五十頁 |
600 | 15,000 | 5 |
ML.TRANSCRIBE |
200 | 10,000 | 5 |
ML.ANNOTATE_IMAGE |
1,800 | 648,000 | 5 |
ML.TRANSLATE |
6,000 | 2,160,000 | 5 |
ML.UNDERSTAND_TEXT |
600 | 21,600 | 5 |
1這項服務會使用動態權杖批次處理功能，盡可能將最多的資料列放入單一要求。實際成效會因嵌入內容長度而異。如要提高每項工作列數上限，請申請 QPM 配額調整。
針對 Gemini 2.0 以上版本的模型執行 BigQuery ML 函式時，系統會使用動態共用配額 (DSQ)，因此配額會根據資源的可用性而異。
如要進一步瞭解 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 個工作天到 1 週。 |
| 每個查詢的資料列數量上限 | 70 億 | 每個查詢的資料列數量上限。 |
BigQuery sharing (舊稱 Analytics Hub)
以下限制適用於 BigQuery sharing (原為 Analytics Hub)：
| 限制 | 預設 | 附註 |
|---|---|---|
| 每項專案的資料交換數量上限 | 500 次交換 | 您最多可以在一個專案中建立 500 個資料交換。 |
| 每個資料交換項目的商家資訊數量上限 | 1,000 個產品資訊 | 您最多可以在資料交換中建立 1,000 個產品資訊。 |
| 每個共用資料集的連結資料集數量上限 | 1,000 個已連結的資料集 | 所有 BigQuery 共用訂閱者，每個共用資料集最多可連結 1,000 個資料集。 |
Dataplex 通用目錄自動探索功能
以下限制適用於 Dataplex 通用目錄自動探索功能：
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個探索掃描支援的 Cloud Storage 值區中，BigQuery、BigLake 或外部資料表的最大數量 | 每個值區 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 擷取結果的 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 連線使用情形 | 每分鐘 100 個連線用量 | 專案每分鐘最多可使用 BigQuery Omni 連線 100 次。這項限制適用於使用連線存取 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 旗標篩選資料庫，藉此縮減中繼資料檔案大小。 |
以下配額適用於 BigQuery Migration API。在大多數情況下，下列預設值會套用。您的專案預設值可能不同：
| 配額 | 預設 | 附註 |
|---|---|---|
|
每分鐘的 EDWMigration 服務清單要求次數 EDWMigration 服務清單要求數，每位使用者每分鐘 |
12,000 項要求 2,500 項要求 |
專案每分鐘最多可提出 12,000 個 Migration API 清單要求。 每位使用者每分鐘最多可提出 2,500 個 Migration API 清單要求。 在 Google Cloud 控制台中查看配額 |
|
EDWMigration Service Get Requests per minute 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 其他要求數 (每位使用者每分鐘) |
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 個要求 |
每個專案最多可在每個區域每分鐘呼叫 100 次
SearchAllAssignments 方法。在 Google Cloud 控制台中查看配額 |
每位使用者每個地區每分鐘的 SearchAllAssignments 要求數 |
10 項要求 |
每位使用者每分鐘最多可對每個區域的
SearchAllAssignments 方法提出 10 次呼叫。在 Google Cloud 控制台查看配額 (在 Google Cloud 控制台搜尋結果中搜尋「per user」)。 |
BigQuery Data Policy API
下列限制適用於 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 中使用預設串流時，建議您使用儲存空間寫入 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
request size
|
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 錯誤。 |
如需額外的串流配額，請參閱「要求增加配額」。
頻寬
複製頻寬適用下列配額：
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域的初始回填複製頻寬上限，這些區域會從主要備用資源將資料傳送至次要備用資源。 | 每個機構每個區域 10 GiBps | |
| 每個區域的持續複製頻寬上限，該區域有從主要備用資源傳出至次要備用資源的跨區域資料。 | 每個機構每個區域 5 GiBps | |
| 每個區域的最大強化型複製頻寬，這些區域會從主要備用資源將跨區域資料傳送至次要備用資源。 | 每個機構每個區域 5 GiBps | 強化型複製頻寬配額不適用於初始候補作業。 |
如果專案的複製頻寬超過特定配額，受影響專案的複製作業可能會停止，並顯示 rateLimitExceeded 錯誤，其中包含超過配額的詳細資料。