配額與限制

本頁提供 Cloud SQL 配額與限制的相關資訊。配額適用於專案層級；限制則視本身特性，可能適用於執行個體，也可能適用於專案層級。

配額

配額會限制 Google Cloud 專案可使用的 Google Cloud 資源數量，Cloud SQL 就是這類資源。

Cloud SQL 的配額系統具備以下功能：

  • 監控 Cloud SQL 執行個體的使用量或消耗量
  • 限制這些執行個體的用量，以確保公平性並減少用量劇烈波動
  • 維護自動強制執行規定限制的設定
  • 提供變更或要求變更配額的方法

如果超過配額，系統通常會立即封鎖相關執行個體的存取權，您嘗試執行的工作也會失敗。配額會套用至各個 Google Cloud 專案，並由使用該專案的所有執行個體共用。

檢查及提高配額的權限

如要查看及提高配額，您必須具備下列權限：

根據預設，編輯者和擁有者這些基本 IAM 角色，以及預先定義的配額管理員角色，都擁有這些權限。如需其他權限，請與配額管理員聯絡。

查看配額

如要查看專案中資源目前的配額，請前往Google Cloud 控制台的「Quotas」(配額) 頁面，然後篩選「Cloud SQL Admin API」。這些配額僅適用於 API 呼叫，不包括資料庫查詢。

提高配額

隨著您的 Google Cloud 使用量增加，配額也會隨之提高。如果您預期用量將有顯著增長，請提早幾天提出要求，確保配額充足。

申請提高配額不會產生任何費用。除非使用的資源更多，否則費用不會增加。

如要提高配額，請按照下列步驟操作：

  1. 前往 Google Cloud 控制台的「Quotas」(配額) 頁面。

    前往「配額」頁面

  2. 篩選 Cloud SQL Admin API 服務。

    如果找不到這項服務，請啟用 Cloud SQL Admin API。

  3. 找出要變更的配額，然後勾選旁邊的核取方塊並按一下「編輯配額」。

  4. 在「New limit」(新限制) 欄位中，為所選的每項配額輸入所需限制值。

  5. 在「Reason description」(原因說明) 欄位中，輸入要求增加配額的原因，然後按一下「Done」(完成)。

  6. 點選「下一步」。

  7. 填寫姓名、電子郵件地址和電話號碼，然後按一下「提交要求」。

    如果無法提高配額，請提交支援案件。

資源配額的補充方式

每日配額會在太平洋時間午夜重設。

配額與資源可用性

在資源供應無虞的前提下，資源配額指的是您能夠建立特定類型資源的數量上限。配額並無法保證您隨時可以使用這些資源，如果某項資源在您所在區域沒有實體可用，即使專案仍有剩餘配額，您也無法建立該類型的資源。

頻率配額

Cloud SQL 支援頻率配額，也稱為頻率限制或 API 配額。頻率配額會定義您可以向 Cloud SQL Admin API 發出的要求數量。

每個頻率配額都對應到一或多個 Cloud SQL Admin API 方法類別的所有要求。頻率配額會在 Cloud SQL 專屬的時間間隔過後重設 (例如每分鐘的 API 要求數)。

使用 gcloud CLI 或 Google Cloud 控制台時，您會向 Cloud SQL Admin API 提出要求，這些要求會計入頻率配額。如果您使用服務帳戶存取 API，這些要求也會計入頻率配額。

Cloud SQL 會每隔 60 秒自動強制執行及補充頻率配額。如果專案在 60 秒內達到頻率配額上限，您必須等待該配額重新填滿，才能在該類別中提出更多要求。如果專案超出這項限制，您會收到 HTTP 429 狀態碼，原因為 rateLimitExceeded。

Cloud SQL Admin API 分為下列類別：

  • 連線：查詢連線至 Cloud SQL 資料庫所需的值。
  • Get：擷取資源的相關資訊 (例如執行個體、作業或備份)。
  • List：列出資源。
  • Mutate：建立、修改及刪除資源。
  • 各區域預設：與 Cloud SQL 執行個體互動，但不連線、擷取、列出或變更。
  • 預設：列出 Cloud SQL 執行個體的資料庫旗標和機型 (級別)。這個類別的 API 適用於全球。

Cloud SQL 會針對每個類別，依每分鐘、每位使用者和每個區域設定頻率配額。Cloud SQL 會針對這些屬性的每個不重複組合，分別設定頻率限制。

Cloud SQL Admin API 會產生詳細指標，協助您追蹤 API 用量、監控 Cloud SQL 執行個體和 API 的效能，以及找出執行個體和 API 之間的問題。詳情請參閱「監控 API 用量」。

下表提供各類別的指標、API 和預設限制資訊：

類別 指標 API 預設限制
連結

sqladmin.googleapis.com/connect

每位使用者在每個區域每分鐘提出的要求數量，用於使用這個類別的 API。

 1000
取得

sqladmin.googleapis.com/get

每位使用者在每個區域每分鐘可提出的要求數量，用於使用這個類別中的 API。

 500
清單

sqladmin.googleapis.com/list

每位使用者在每個區域每分鐘可提出的要求數量，用於使用這個類別中的 API。

 500
更改

sqladmin.googleapis.com/mutate

每位使用者在每個區域，每分鐘可發出多少要求，以使用這個類別的 API。

 180
每個區域的預設值

sqladmin.googleapis.com/
default_per_region

每位使用者在每個區域每分鐘可發出的預設區域要求數量，用於使用這個類別的 API。

 180
預設

sqladmin.googleapis.com/default

每位使用者每分鐘預設可提出的要求數量，用於使用這個類別的 API。

 180

排解頻率限制錯誤

Cloud SQL 會依每分鐘、每位使用者和每個區域強制執行頻率配額，因此 Google Cloud 控制台的「Cloud Quotas」(Cloud 配額) 頁面不會顯示每位使用者的配額用量。如果單一使用者或服務帳戶用盡每位使用者的速率配額，Cloud SQL Admin API 會傳回 HTTP 429 Too Many Requests 狀態碼，並附上 rateLimitExceeded 原因。在這種情況下，「Cloud Quotas」頁面上的匯總專案層級配額指標，可能會顯示配額仍可用。

如要診斷哪個使用者或服務帳戶已用盡每位使用者的速率限制，請完成下列步驟：

  1. 在 Google Cloud 控制台中，選取啟動 Cloud SQL 要求的消費者專案，然後前往「指標探索工具」頁面。
  2. 按一下「Select a metric」(選取指標)，然後在篩選列中輸入 serviceruntime.googleapis.com/api/request_count。在 子選單中，依序選取 「已使用的 API」>「API」> 「要求數量」，然後按一下 「套用」。
  3. 在「Filter」(篩選器) 元素中，新增下列篩選器來找出遭到節流的請求：
    1. 按一下「新增篩選器」，然後選取「response_code」。在篩選器對話方塊中，將「Comparator」(比較子) 設為「= (equals)」(= (等於))，在「Value」(值) 欄位中輸入 429，然後按一下「Apply」(套用)。
    2. 再次按一下「新增篩選條件」，然後選取 service。將「比較子」設為「= (等於)」，在「值」欄位中輸入 sqladmin.googleapis.com，然後按一下「套用」。
    3. 選用：如要依特定 API 方法篩選，請按一下「Add filter」(新增篩選器)，然後選取「method」。將「比較子」設為「= (等於)」，在「值」欄位中輸入方法名稱 (例如 google.cloud.sql.v1.SqlInstancesService.Get)，然後按一下「套用」。
  4. 在「Aggregation」(匯總) 元素中，確認第一個選單已設為「Sum」(總和)，然後在第二個選單 (「by」(依據) 旁邊) 選取 credential_id，依個別憑證將要求計數分組。
  5. 在結果中，找出 429 回應代碼數量最多的憑證 ID (credential_id)。這個值是服務帳戶或使用者憑證的 OAuth 2.0 用戶端 ID，這些憑證已用盡每位使用者的速率限制。
  6. 如要找出與該用戶端 ID 對應的服務帳戶，請前往Google Cloud 控制台的「Service accounts」(服務帳戶) 頁面，然後在篩選器方塊中輸入 OAuth 2.0 用戶端 ID。相符的項目就是耗盡每位使用者頻率限制的服務帳戶。

找出服務帳戶後，請採取下列一或多項緩解措施，解決錯誤：

  • 實作用戶端快取：如果應用程式經常輪詢執行個體中繼資料 (例如在容器重新啟動或健康狀態檢查期間)，請快取執行個體中繼資料，避免重複呼叫 SqlInstancesService.Get。
  • 套用指數輪詢：確保用戶端重試邏輯使用指數輪詢和抖動，避免傳送超出速率限制的大量要求。
  • 在服務帳戶之間分配工作負載：如果多個工作負載共用單一服務帳戶或消費者專案，請為每個工作負載建立專屬服務帳戶，避免某個工作負載耗用共用配額。
  • 要求調整配額：如果應用程式需要較高的處理量，請要求提高 Cloud SQL Admin API 頻率配額。

限制

部分 Cloud SQL 資源設有限制，不會定期補充，也不會顯示在 Google Cloud 控制台的「配額」頁面。您可以要求放寬某些資源的限制，但有些限制無法更動。

可調整的限制

每項專案的執行個體數

單一專案中可擁有的執行個體數量上限，取決於這些執行個體的網路架構：

  • 全新 SQL 網路架構：每個專案最多可有 1,000 個執行個體。
  • 舊版 SQL 網路架構：每個專案最多可有 100 個執行個體。
  • 同時使用兩種架構：上限介於 100 到 1,000 之間，視執行個體在兩種架構中的分配情形而定。

提交客服案件，要求提高配額。唯讀副本會計為執行個體。

建議您將執行個體數量分配到多個專案，減少對配額提高要求的依賴。這有助於避免任何潛在的阻礙。

並行連線數上限

MySQL

您可以使用 max_connections 標記設定連線限制。建立 MySQL 適用的 Cloud SQL 執行個體時，請選擇決定記憶體容量的機型。可用記憶體大小會決定執行個體的連線限制。

如要查看執行個體的連線數量限制，請連線至資料庫並執行下列指令： SHOW VARIABLES LIKE "max_connections";

PostgreSQL

您可以使用 max_connections 旗標設定連線數量限制。建立 PostgreSQL 適用的 Cloud SQL 執行個體時， 機型設定會根據您選取的核心數量，自動調整可用的記憶體大小範圍。這也會決定執行個體的初始預設連線限制。

如要查看執行個體的連線限制，您可以連線至資料庫並執行以下指令：SELECT * FROM pg_settings WHERE name = 'max_connections';

備用資源中的值不能小於主要執行個體中的值。主要執行個體的變更會套用至值低於主要執行個體新值，或未從預設值變更的副本。

如果主要執行個體的值為 default，則無法變更副本的值。如要變更副本的值，請先將主要執行個體的值設為整數。

SQL Server

您所使用的 SQL Server 版本，以及應用程式或應用程式與硬體的限制，會決定您實際可用的使用者連線數量。SQL Server 最多可允許 32,767 個使用者連線。

如要瞭解如何在 SQL Server 中設定使用者連線，請參閱參考文件。

注意事項

Cloud SQL 連接器的配額用量

Cloud SQL Auth Proxy 和其他 Cloud SQL 連接器會使用 Cloud SQL Admin API 的配額。Cloud SQL 連接器大約每小時會執行一次重新整理作業。這項重新整理作業會發出兩次 API 呼叫。一個呼叫會擷取執行個體中繼資料，另一個呼叫則會擷取臨時憑證。

配額用量的計算方式如下：

Quota usage = connector processes running * instances * 2 API calls per hour

舉例來說，如果您有三個程序正在執行連接器，連接器已設定為連線至兩個 Cloud SQL 執行個體，且在一小時內發出兩次 API 呼叫，則配額用量為 12 (3 個程序 * 2 個執行個體 * 2 次 API 呼叫)。

如果您剛開始使用 Cloud SQL，請記住上述公式，並注意下列事項：

  • 您擴大新 DB 客戶的速度

  • 新增執行個體的速度

  • 為每個應用程式使用不同的服務帳戶

Cloud SQL IAM 資料庫驗證

每個執行個體每分鐘都有登入配額，包括成功和失敗的登入。超過配額時，系統會暫時停用登入功能。建議您避免頻繁登入，並使用授權網路限制登入。 登入授權配額為每分鐘 12,000 次 (每個執行個體)。

轉送規則配額

每個 Cloud SQL 執行個體都包含轉送規則和負載平衡器。轉送規則的配額限制取決於所指向的負載平衡器類型。 每項專案、網路和對等群組，對各類轉送規則都有多項配額。Cloud SQL 也有每個網路配額和每個對等群組配額的覆寫規則。也就是說，當我們提高供應商網路的每個網路配額時，每個對等群組的配額也會提高到相同的值。

Cloud SQL 供應商虛擬私有雲與客戶的虛擬私有雲對等互連，因此我們經常達到 Cloud SQL 供應商網路的每個網路配額，以及客戶虛擬私有雲的每個對等群組配額。

達到配額後，部分作業可能會失敗，包括：

  • 建立作業：建立新執行個體時，需要新的轉送規則。

  • 更新作業：我們允許客戶切換執行個體的網路，因此需要在新網路中設定新的轉送規則。

  • 維護作業：重新建立轉送規則。

為避免發生問題，建議您將每個網路的執行個體總數限制在 500 個以下。

如果遇到問題，請提交客服案件，我們會為您提高相關配額。

固定限制

IOPS

IOPS 是指磁碟每秒可處理的輸入/輸出作業 (或讀取/寫入) 數量。

Cloud SQL 會使用搭載永久儲存空間磁碟的 Compute Engine 虛擬機器 (VM)。如要進一步瞭解特定 VM 的效能特性，請參閱永久磁碟效能頁面上的持續 IOPS 上限表格。

資料表限制

MySQL 適用的 Cloud SQL 預設限制為 50,000 個資料表，如果符合最低硬體需求 (至少 32 個核心和 200G 記憶體)，則執行個體可有 500,000 個資料表。為獲得最佳效能，建議單一資料庫中的資料表數量不要超過 50,000 個。

服務水準協議不適用於超過這些限制的執行個體。如果啟用 innodb_file_per_table 資料庫旗標，且資料表大小達到 16 TB (Linux 分割區的大小上限)，就無法再新增資料。

執行個體所需的記憶體取決於多項因素。如要進一步瞭解 MySQL 適用的 Cloud SQL 如何使用記憶體，請參閱「MySQL 如何使用記憶體」。

如果有效資料表數量大於 Cloud SQL 預設值，或整體快取大小相當大，則必須調整執行個體。如要維持最佳效能，請採取下列措施：

  • 升級至 Cloud SQL Enterprise Plus 版本，即可選用更高的記憶體。
  • 升級 Cloud SQL 機器，為執行個體新增記憶體。
  • 調低 innodb_buffer_pool_size 資料庫旗標的值。

table_open_cache 和 table_definition_cache 旗標可用於修改 MySQL 適用的 Cloud SQL 資料表快取。您可以使用成效結構定義，預估執行個體的資料表快取大小。詳情請參閱 MySQL 說明文件。

如果作用中資料表的數量遠大於 Cloud SQL 資料表預設值和 MySQL 建議的開啟資料表數量，Cloud SQL 建議您使用執行個體的作用中資料表數量，設定 table_open_cache 和 table_definition_cache 資料庫旗標。詳情請參閱「MySQL 開啟及關閉資料表的方式」。

PostgreSQL 適用的 Cloud SQL 的資料表大小上限為 32 TB。 資料表大小達到 32 TB 後，就無法再新增資料。

作業數量上限

微型和小型級別機型會限制並行作業數量。如果超過限制，系統就會傳回 Too many operations 錯誤。

db-custom-1-3840 (單一 CPU) 機器類型限制為 50 個並行作業。

ExecuteSQL 限制

ExecuteSql REST API 的要求有下列限制：

  • 每個執行個體一次最多只能有 10 項並行查詢。
  • 查詢的頻率限制為每項專案每分鐘 100 個查詢 (每個區域)。
  • 要求的大小上限為 512 KiB (0.5 MiB)，回應則不得超過 10 MiB。

指標收集限制

系統最多會收集 500 個資料庫的 PostgreSQL 指標。如果資料庫超過 500 個，則特定指標只會納入前 500 個。這些資料庫的交易次數最多。

Cloud SQL 儲存空間限制

  • 專屬核心：最多 64 TB。

  • 共用核心：最多 3 TB。

    詳情請參閱「執行個體定價」。

Cloud SQL 儲存空間選項

如要設定儲存空間選項，以獲得最佳效能，請務必瞭解您的工作負載，並選擇適當的磁碟類型和大小。如要進一步瞭解我們為 Cloud SQL 提供的各種選擇，請參閱執行個體設定的相關說明。

App Engine 限制

以 App Engine 標準環境來說，當中運作的執行個體與其他執行個體之間的並行連線數不得超過 100 個。如果是以 PHP 5.5 編寫而成的應用程式，則上限為 60 個並行連線。

App Engine 應用程式必須符合要求時間限制，實際情況則視用量和環境而定。詳情請參閱如何管理 App Engine 標準環境的執行個體： 標準和 彈性環境。

App Engine 應用程式也必須符合其他 App Engine 配額與限制的規定，詳情請參閱 App Engine 配額頁面。

Cloud Run 限制

如果您在 Cloud Run 上使用內建的 Cloud SQL 連線，則 Cloud Run 容器執行個體每個 Cloud SQL 資料庫最多只能有 100 個連線。

Cloud Run 服務或工作的每個執行個體，最多可與資料庫建立 100 個連線。隨著服務或工作規模擴大，每次部署的連線總數也會增加。

如果使用其他連線方式，例如在 sidecar 中使用 Cloud SQL Auth Proxy、Cloud SQL 語言連接器，或直接連線至 Cloud SQL 執行個體的 IP 位址，則不適用這項限制。

Cloud Run functions 限制

Cloud Run functions (第 1 代) 會將每個執行個體的並行執行次數限制為一次。您絕不會遇到單一第 1 代函式執行個體同時處理兩項要求的情況。在多數情況下，您只需要一個資料庫連線。

Cloud Run functions (第 2 代) 以 Cloud Run 為基礎，每個執行個體最多可建立 100 個資料庫連線。

已儲存的查詢限制

值 限制
每個專案可儲存的查詢數量上限 (包括其他 Google Cloud 產品的已儲存查詢) 10,000
每個查詢的大小上限 1 MiB

Cloud SQL 儲存空間限制

  • 專屬核心：最多 64 TB。

  • 共用核心：最多 3 TB。

    詳情請參閱「執行個體定價」。

Cloud SQL 儲存空間選項

如要設定儲存空間選項，以獲得最佳效能，請務必瞭解您的工作負載，並選擇適當的磁碟類型和大小。如要進一步瞭解我們為 Cloud SQL 提供的各種選擇，請參閱執行個體設定的相關說明。

App Engine 限制

以 App Engine 標準環境來說，當中運作的執行個體與其他執行個體之間的並行連線數不得超過 100 個。如果是以 PHP 5.5 編寫而成的應用程式，則上限為 60 個並行連線。

App Engine 應用程式必須符合要求時間限制，實際情況則視用量和環境而定。詳情請參閱 App Engine 標準和 彈性環境中的執行個體管理方式。

App Engine 應用程式也必須符合其他 App Engine 配額與限制的規定，詳情請參閱 App Engine 配額頁面。

Cloud Run 限制

如果您在 Cloud Run 上使用內建的 Cloud SQL 連線，則 Cloud Run 容器執行個體每個 Cloud SQL 資料庫最多只能有 100 個連線。

Cloud Run 服務或工作的每個執行個體，最多可與資料庫建立 100 個連線。隨著服務或工作規模擴大，每次部署的連線總數也會增加。

如果使用其他連線方式，例如在 sidecar 中使用 Cloud SQL Auth Proxy、Cloud SQL 語言連接器，或直接連線至 Cloud SQL 執行個體的 IP 位址，則不適用這項限制。

Cloud Run functions 限制

Cloud Run functions (第 1 代) 會將每個執行個體的並行執行次數限制為一次。您絕不會遇到單一第 1 代函式執行個體同時處理兩項要求的情況。在多數情況下，您只需要一個資料庫連線。

Cloud Run functions (第 2 代) 是以 Cloud Run 為基礎，每個執行個體最多可有 100 個資料庫連線。