Cloud SQL 入門：版本、HA、連線與備份怎麼選

應用原本就使用 MySQL、PostgreSQL 或 SQL Server，又不想自己維護資料庫主機時，Cloud SQL 通常是 GCP 上最先評估的服務。

「全托管」不代表資料庫會自己顧好一切。Google 會處理底層主機、修補和部分維運工作，但版本、容量、帳號、查詢、備份保留期和災難復原仍然是使用者的責任。這篇會沿著實際建立執行個體的順序，說明每一項設定該怎麼選。

一、Cloud SQL 幫你管什麼，又不管什麼？

Cloud SQL 是 Google Cloud 的全托管關聯式資料庫服務，支援 MySQL、PostgreSQL 和 SQL Server。可建立的版本會持續更新；截至本文查核時間，常見選擇如下：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Google 主要負責：

• 作業系統更新與安全修補
• minor version 和維護更新
• 執行自動備份與儲存擴充等已啟用的功能
• 維護你選擇的高可用基礎設施

使用者仍要處理 schema、資料庫帳號、查詢效能、連線池、容量監控，以及備份和復原目標。Major version 升級也需要自行規劃，不能假設平台會替應用處理相容性問題。

二、版本怎麼選：先看相容性，再追新功能

MySQL

• 9.7：新 major version，採用前先確認 driver、ORM、外掛和團隊工具是否支援。
• 8.4：目前的預設版（用 gcloud 建立時仍要自己帶 --database-version，指令參考頁寫未指定時用的是 MYSQL_8_0），也是適合新專案評估的 LTS 選擇。
• 8.0：適合仍受既有應用相容性限制的系統，但要把支援期限放進升級計畫。

MySQL 5.7 和 5.6 已進入 Cloud SQL 延伸支援。保留舊版本可能多出費用，也會讓之後的升級更難；除非是遷移過渡期，否則不要拿來建立新系統。

PostgreSQL

• 18：目前的預設版，適合已確認 extension 和 driver 相容性的新專案。
• 17、16：如果組織需要較長的驗證期，可以選已被既有工具完整支援的版本。
• 14、15：較常出現在舊系統遷移；選擇前要先看進入延伸支援的日期。

不要只因為版本最新就直接上線。先列出應用會使用的 extension、collation、driver 和 replication 功能，再用測試資料跑升級與回復演練。

SQL Server

SQL Server 除了年份，還要選 Standard、Enterprise、Express 或 Web 等 edition，實際選項依 major version 而異。Edition 會影響功能和授權費，所以遷移前要一起盤點 SQL Server Agent、企業版功能、相容性層級和授權成本，而不是只確認年份相同。

三、Edition 和機型：SLA 不能只看機器大小

Cloud SQL 的配置可以先分成 Shared core 和 Dedicated core。前者適合低成本測試，後者再依 Enterprise 或 Enterprise Plus edition 選擇機器系列。

Shared Core：只拿來開發和測試

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

db-f1-micro 和 db-g1-small 不在 Cloud SQL SLA 的涵蓋範圍內。它們適合開發、測試或可隨時重建的非關鍵環境，不該只因為便宜就拿來承載正式服務。

Dedicated Core：正式環境的起點

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

99.95% 和 99.99% 的 SLA 分別對應啟用 HA 的 Enterprise 與 Enterprise Plus，不是單靠選一台較大的機器就能取得。Shared core、single-zone 執行個體也不在這兩項 SLA 的涵蓋範圍內。

flowchart TB
  subgraph REQUIREMENT["定義需求"]
    direction LR
    START["定義環境、SLA、延遲、<br/>讀寫量與可接受停機"] --> PROD{"是否為需要 SLA 的<br/>正式或關鍵工作負載？"}
  end
  PROD -->|"否，開發／測試／非關鍵"| SHARED["Shared Core<br/>成本低，但沒有 SLA"]
  PROD -->|"是"| PLUS{"是否需要 99.99% SLA、<br/>近乎無感維護或 Data Cache？"}
  subgraph EDITION["Edition 與機型候選"]
    direction LR
    PLUS -->|"是"| ENTERPRISE_PLUS["Enterprise Plus<br/>perf-optimized + 快取"]
    PLUS -->|"否"| ENTERPRISE["Enterprise<br/>dedicated custom／N4"]
  end
  SHARED --> SIZE["以連線數、CPU、記憶體、IOPS<br/>和尖峰負載做容量測試"]
  ENTERPRISE_PLUS --> SIZE
  ENTERPRISE --> SIZE
  subgraph OPERATE["驗證與營運"]
    direction LR
    SIZE --> HA["獨立決定 Regional HA<br/>tier 不等於可用性設計"]
    HA --> REVIEW["用 Query Insights／Monitoring 調整<br/>tier 變更前安排重啟窗口"]
  end

四、HA 保服務可用，Read replica 才負責分攤讀取

Cloud SQL 的 Regional HA 會在同一個 Region 的兩個 Zone 放置 primary 和 standby，並透過 regional persistent disk 同步資料：

┌──────────────────────────────────────┐
│          us-central1 (Region)        │
│                                      │
│  ┌──────────────┐  ┌──────────────┐  │
│  │  Primary     │  │  Standby     │  │
│  │  (Zone A)    │  │  (Zone B)    │  │
│  └──────┬───────┘  └──────┬───────┘  │
│         │                 │           │
│         └────────┬────────┘           │
│                  │                    │
│    ┌─────────────▼────────────┐       │
│    │  Regional Persistent Disk│       │
│    │ (兩個 Zone 各一份，同步複寫) │       │
│    └──────────────────────────┘       │
└──────────────────────────────────────┘

這套架構有幾個重點：

• 使用 Regional Persistent Disk，將寫入同步複寫到兩個 Zone 各自的磁碟，交易必須在兩個 Zone 的磁碟都寫入才算 commit（因此會有同步複寫的延遲，regional disk 的寫入延遲高於 zonal disk）
• 故障切換期間通常會中斷約 60 秒，但實際時間仍會受環境和連線重試影響
• 備用節點不對外提供讀取服務（與 RDS 的 Multi-AZ DB instance 部署類似）
• 啟用 HA 後費用約 2 倍（primary + standby）

standby 不接受應用程式查詢，因此開啟 HA 不會多出一個可讀節點。它買的是區域內的可用性：primary 或所在 Zone 故障時，Cloud SQL 讓 standby 接手同一個 IP。若瓶頸是大量 SELECT，要另外建立 read replica，並由應用把讀取流量導過去。

啟用 HA：

# 建立時啟用
gcloud sql instances create my-db \
  --database-version=POSTGRES_16 \
  --edition=ENTERPRISE_PLUS \
  --tier=db-perf-optimized-N-2 \
  --region=us-central1 \
  --availability-type=REGIONAL  # 預設是 ZONAL（無 HA）

五、連線要拆成網路、授權和資料庫登入三層

Cloud SQL 連線最容易講亂，是因為大家常把不同層次的選項放在同一張排行榜。實際上要分成三個問題：

1. 封包走 public IP、Private Services Access，還是 Private Service Connect（PSC）？
2. 應用直接管理 TLS，還是使用 Cloud SQL Auth Proxy／Language Connector？
3. 登入資料庫時使用內建帳號密碼，還是 IAM database authentication？

這些選項可以組合。例如應用可以透過 PSC 的私有路徑，再使用 Auth Proxy 處理 IAM 授權和 TLS。

Cloud SQL Auth Proxy：處理連線授權和 TLS

Cloud SQL Auth Proxy 會先用 IAM 確認呼叫者具有 cloudsql.instances.connect 權限，再用自動輪替的憑證建立 TLS 連線。它不會憑空建立新的網路路徑：使用 private IP 時，Proxy 所在的主機仍然要能連到該 VPC。

# 安裝最新版本後，在應用程式所在主機啟動
./cloud-sql-proxy \
  --port=5432 \
  PROJECT_ID:REGION:INSTANCE_NAME

應用程式連線：

Host: 127.0.0.1
Port: 5432
User: app-user
Password: ****
Database: mydb

它的主要好處是：

• 自動加密（TLS）
• 使用 IAM 授權連線，不必為 public IP 設定 authorized networks
• 自動處理 Cloud SQL 憑證，不必在應用裡自行輪替

Proxy 只授權「能不能連到這個執行個體」，資料庫帳號本身仍要另外驗證。Java、Python 和 Go 應用也可以直接使用對應的 Cloud SQL Language Connector。

Private Service Connect：建立受控的私有端點

PSC 適合讓多個 VPC、專案或組織透過各自的內部端點連到 Cloud SQL，並避免傳統 peering 的路由和 IP 範圍耦合。它不是 Auth Proxy 的替代品，而是網路拓樸的選擇。

# 建立支援 PSC 的 Cloud SQL 執行個體
gcloud sql instances create my-db \
  --database-version=MYSQL_8_0 \
  --tier=db-custom-2-7680 \
  --region=us-central1 \
  --no-assign-ip \
  --enable-private-service-connect \
  --allowed-psc-projects=PROJECT_ID

PSC 和 Private Services Access（底層使用 VPC Network Peering）的差別，可以先這樣看：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Public IP：不等於公開放行，但要縮小攻擊面

如果應用只能經由網際網路連線，可以使用 public IP。直接連線時要配置 authorized networks，並自行強制 TLS：

gcloud sql instances patch my-db \
  --authorized-networks=203.0.113.10/32

另一種做法是讓 Auth Proxy 或 Language Connector 走 public IP。這種情況不需要把來源加入 authorized networks，但執行個體仍有外部 IP，IAM、資料庫帳號和最小權限一樣不能省略。有條件使用私有網路時，通常能減少對外暴露面。

flowchart TB
  subgraph PATH["第一層：網路路徑"]
    direction LR
    START["應用程式需要<br/>連到 Cloud SQL"] --> NETWORK{"流量應走哪條<br/>網路路徑？"}
    NETWORK -->|"私有、跨專案或避免 peering 衝突"| PSC["PSC<br/>受控私有端點"]
    NETWORK -->|"既有 Private IP／VPC Peering"| PEERING["沿用 Private IP<br/>治理路由與 IP"]
    NETWORK -->|"需要從 VPC 外部連線"| PUBLIC["Public IP<br/>縮小白名單或搭配 Connector"]
  end
  PSC --> AUTH{"第二層：應用如何驗證並加密連線？"}
  PEERING --> AUTH
  PUBLIC --> AUTH
  subgraph IDENTITY["第二層：驗證與加密"]
    direction LR
    AUTH -->|"可用 Connector／Auth Proxy"| PROXY["IAM 驗證 + TLS<br/>自動處理憑證"]
    AUTH -->|"driver 必須直接連線"| DIRECT["強制 TLS + 最小資料庫帳號<br/>Secret Manager 輪換密碼"]
    PROXY --> VERIFY["驗證 DNS、路由、IAM、<br/>連線池、逾時與憑證更新"]
    DIRECT --> VERIFY
  end

六、建立資料庫與應用程式帳號

# 建立資料庫
gcloud sql databases create mydb --instance=my-db

# 建立使用者（MySQL）
gcloud sql users create app-user \
  --instance=my-db \
  --password=SecurePassword123!

# 建立使用者（PostgreSQL IAM database authentication）
gcloud sql users create "sa-name@project.iam" \
  --instance=my-db \
  --type=cloud_iam_service_account

# 列出所有使用者
gcloud sql users list --instance=my-db

# 連線到資料庫（透過 Cloud Shell）
gcloud sql connect my-db --user=app-user --database=mydb

PostgreSQL 的 IAM 範例要先在執行個體啟用 cloudsql.iam_authentication flag，並授予服務帳號 Cloud SQL Instance User 等必要 IAM 權限。因資料庫使用者名稱有長度限制，service account 名稱要省略 .gserviceaccount.com 後綴。

七、備份和 PITR：先寫下要回到哪個時間點

自動備份

# 設定備份開始時間，並保留最近 7 份自動備份
gcloud sql instances patch my-db \
  --backup-start-time=02:00 \
  --retained-backups-count=7

Cloud SQL 現在有 standard 和 enhanced backup 兩種選項，排程、集中管理與可設定保留期不同。自動備份的保留範圍也會依所選方案而變，不要只依賴建立畫面的預設值；應按照 RPO、稽核要求和刪除執行個體後是否仍需保留備份來設定。

隨選備份

gcloud sql backups create --instance=my-db

時間點還原（PITR）

PITR 不只回到某一份備份完成的時間，而是利用 PostgreSQL 的 WAL 或 MySQL 的 binlog，把交易重播到保留範圍內的指定時間。這很適合處理誤刪資料或錯誤批次更新：

# 啟用 PITR（要先開自動備份；這是 PostgreSQL 的寫法，MySQL 改用 --enable-bin-log）
gcloud sql instances patch my-db \
  --enable-point-in-time-recovery

# 還原到特定時間（PITR 是 clone 出一個新 instance）
gcloud sql instances clone my-db my-db-restored \
  --point-in-time='2026-03-10T12:00:00.000Z'

PITR 會保留額外的 transaction log，也會產生相應費用。還原結果是一個新的執行個體，不會直接把原資料庫倒回去；切換應用前，要先比對資料、帳號、extension 和 schema。

flowchart TB
  START["偵測到 Cloud SQL 不可用<br/>或資料內容異常"] --> FAILURE{"問題屬於哪一類？"}
  FAILURE -->|"Primary／Zone 故障，資料本身正常"| HA{"是否已啟用 Regional HA？"}
  HA -->|"是"| FAILOVER["等待／觸發 Failover<br/>共用端點跟隨新的 Primary"]
  HA -->|"否"| OUTAGE["依災難復原 Runbook<br/>從備份建立替代執行個體"]
  FAILURE -->|"誤刪、錯誤更新，知道事故時間"| PITR["PITR clone 到事故前一刻<br/>建立新的 recovery instance"]
  FAILURE -->|"只需回到某次備份時間點"| RESTORE["從選定 Backup 還原<br/>避免未驗證就覆蓋唯一可用副本"]
  FAILOVER --> VALIDATE["驗證資料完整性、Schema、帳號、<br/>應用讀寫與 replication 狀態"]
  OUTAGE --> VALIDATE
  PITR --> VALIDATE
  RESTORE --> VALIDATE
  VALIDATE --> CUTOVER["更新連線／流量並監控<br/>保留原執行個體供調查"]
  CUTOVER --> REVIEW["記錄 RTO／RPO 與根因<br/>修正備份、HA 和演練頻率"]

八、儲存會自動長大，也能手動縮小

儲存設定

gcloud sql instances create my-db \
  --storage-size=20 \
  --storage-type=SSD \
  --storage-auto-increase

開啟 --storage-auto-increase 後，Cloud SQL 會在可用空間低於門檻時增加配置容量：

• 當可用空間低於門檻值（SSD／HDD：約 5 + 容量/25 GB，最大 25GB）時自動擴充
• 每次擴充量等於門檻值（= 5 + 容量/25，最大 25GB），並非固定 25GB；Hyperdisk Balanced 另有公式（門檻取 5GB 與容量 5% 較大者，每次加 5GB 與容量 15% 較大者）
• 自動增加的容量不會在用量下降後自動縮回去

Storage shrink 不是自動回收

目前可以用 storage shrink 手動降低配置容量，但它會重啟執行個體，磁碟較大時可能造成相當長的停機。Shared-core、read pool、cascading replica 等情境也有限制。執行前先查詢 Cloud SQL 計算出的安全下限、建立備份，並預留至少約 100 GB 或目前用量 20% 的操作空間，兩者取較大值。

因此，auto-increase 仍應搭配告警。它能避免磁碟突然用滿，卻也可能在尖峰後留下較大的配置和帳單；storage shrink 是需要安排維護窗口的修正手段，不是自動縮放機制。

垂直擴充（修改機器類型）

gcloud sql instances patch my-db \
  --tier=db-perf-optimized-N-4

修改 tier 可能需要重啟或造成連線中斷，實際影響取決於 edition、機型和變更方向。先查看該機型的可用性說明，並讓應用具備重連能力；不要把停機時間固定估成 60 秒。

九、Read replica 會減輕讀取壓力，但資料可能落後

Read replica 會非同步接收 primary 的變更。應用必須使用副本自己的 connection name 或 IP，明確把可接受舊資料的查詢送過去：

# 建立讀取副本（同區域）
gcloud sql instances create my-db-replica \
  --master-instance-name=my-db \
  --region=us-central1

# 建立跨區域讀取副本
gcloud sql instances create my-db-replica-asia \
  --master-instance-name=my-db \
  --region=asia-east1

使用前要接受幾項取捨：

• 非同步複寫（可能有延遲）
• 只能執行 SELECT 查詢
• 可提升為獨立執行個體（promote-replica）
• 副本要另外計費，規格太小或查詢太重都可能讓 replication lag 變大

跨 Region 副本也能作為災難復原的一部分，但因為是非同步複寫，Region 發生故障時仍可能遺失尚未套用的交易。提升副本前要先停止 primary 的寫入、確認 lag 已追上，再切換應用連線。

flowchart TB
  START["從 Monitoring、Query Insights<br/>與連線池確認主要瓶頸"] --> BOTTLENECK{"瓶頸是哪一類？"}
  BOTTLENECK -->|"磁碟即將用滿"| STORAGE["啟用／確認 storage auto-increase<br/>同時設用量與成長率告警"]
  BOTTLENECK -->|"少數慢查詢、CPU 或鎖競爭"| QUERY["先最佳化 SQL、索引、交易範圍<br/>與連線池"]
  BOTTLENECK -->|"大量可分離的 SELECT"| READ["建立同區或跨區 Read Replica<br/>應用明確把讀流量導向副本"]
  BOTTLENECK -->|"持續超出單機寫入／全球擴展能力"| REASSESS["重新評估 AlloyDB、Spanner<br/>或資料分割架構"]
  QUERY --> ENOUGH{"最佳化後容量是否足夠？"}
  ENOUGH -->|"否"| VERTICAL["垂直調整 tier<br/>安排重啟或 HA failover 窗口"]
  ENOUGH -->|"是"| MONITOR["持續監控與壓力測試"]
  STORAGE --> MONITOR
  READ --> LAG["監控 replication lag<br/>接受 eventual read consistency"]
  LAG --> MONITOR
  VERTICAL --> MONITOR
  REASSESS --> MONITOR
  HA_NOTE["Regional HA 的 standby<br/>不能承接讀取流量"] -. "不要當成效能擴充" .-> READ

十、成本不只 CPU 和記憶體

一般正式執行個體會依下列資源計費：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

SQL Server 還要加上授權費；使用已進入延伸支援的 MySQL 或 PostgreSQL major version，也會多出 extended support 費用。儲存、備份和網路單價會依 Region 與方案調整，估算時應直接選擇實際部署地區查看 Cloud SQL 官方定價頁。

測試環境不用時，可以用 gcloud sql instances patch INSTANCE_NAME --activation-policy=NEVER 停止執行個體。停止後會暫停 instance compute 費用，但儲存和 IP 位址等資源仍可能收費，而且 read replica 不能用這種方式停止。

Cloud SQL 另有條件受限的 free trial instance，和一般 production 執行個體不是同一種配置。不要把新客戶 credits 或試用方案當成長期免費層來估算正式環境。

十一、什麼時候不該選 Cloud SQL？

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

flowchart TB
  subgraph MODEL["先看資料模型"]
    direction LR
    START["描述交易、查詢、<br/>一致性與擴展需求"] --> RELATIONAL{"需要關聯式 Schema、<br/>交易與 SQL？"}
  end
  RELATIONAL -->|"否"| NOSQL{"主要是文件同步，<br/>還是高吞吐<br/>Key／時序？"}
  subgraph NON_RELATIONAL["NoSQL 候選"]
    direction LR
    NOSQL -->|"文件／行動<br/>Web 即時同步"| FIRESTORE["Firestore"]
    NOSQL -->|"Key／時序<br/>與極高吞吐"| BIGTABLE["Bigtable"]
  end
  RELATIONAL -->|"是"| ANALYTICS{"主要是 OLAP、<br/>掃描大量資料<br/>與 BI 分析嗎？"}
  subgraph SQL_WORKLOAD["SQL 工作負載"]
    direction LR
    ANALYTICS -->|"是"| BIGQUERY["BigQuery"]
    ANALYTICS -->|"否，OLTP"| GLOBAL{"需要全球水平擴展<br/>與強一致交易？"}
  end
  subgraph OLTP["OLTP 候選"]
    direction LR
    GLOBAL -->|"是"| SPANNER["Cloud Spanner"]
    GLOBAL -->|"否"| POSTGRES{"鎖定 PostgreSQL<br/>相容，<br/>且需要更高效能？"}
    POSTGRES -->|"是"| ALLOYDB["AlloyDB"]
    POSTGRES -->|"否"| CLOUDSQL["Cloud SQL<br/>MySQL／<br/>PostgreSQL／<br/>SQL Server"]
  end
  FIRESTORE --> POC["以代表性資料<br/>與查詢做 PoC<br/>驗證延遲、成本、<br/>遷移與營運限制"]
  BIGTABLE --> POC
  BIGQUERY --> POC
  SPANNER --> POC
  ALLOYDB --> POC
  CLOUDSQL --> POC

十二、建立前的快速檢查表

建立或 review 執行個體時，依序確認：

1. 應用、driver、extension 是否支援所選 major version？舊版是否已進入延伸支援？
2. 正式環境是否需要 Regional HA？Edition 對應的 SLA 是否符合需求？
3. 網路路徑用 PSC、Private Services Access 還是 public IP？是否再搭配 Connector？
4. 自動備份、PITR 和 transaction log 各保留多久？團隊實際還原過嗎？
5. Read replica 的查詢能否接受 replication lag？應用是否真的會把讀流量導向副本？
6. Auto-increase、磁碟用量與成長率是否有告警？若要 shrink，可接受多少停機？
7. Region、HA、副本、備份、IP、網路與 extended support 是否都放進成本估算？

四個容易混淆的觀念

• HA 不等於讀取擴充：standby 只負責故障切換，不接受應用查詢。
• Read replica 有自己的端點：應用要主動把讀取送過去，並處理 replication lag。
• 跨 Region 副本不是免費的低延遲捷徑：它能讓遠端使用者就近讀取，但會增加費用，也可能讀到較舊的資料。
• Storage shrink 不等於自動縮容：現在可以手動縮小磁碟，但要安排停機並確認功能限制。

十三、範例：建立一個具備 HA 與 PITR 的 PostgreSQL

下面示範的是配置骨架，不是所有正式環境都該照抄的固定答案。執行前請替換 project、Region、版本和機型，並先建立 PSC 所需的 endpoint、DNS 與網路政策。

# 建立 PostgreSQL 16 執行個體
gcloud sql instances create prod-postgres \
  --database-version=POSTGRES_16 \
  --edition=ENTERPRISE_PLUS \
  --tier=db-perf-optimized-N-2 \
  --region=asia-east1 \
  --availability-type=REGIONAL \
  --storage-size=50GB \
  --storage-type=SSD \
  --storage-auto-increase \
  --backup-start-time=03:00 \
  --retained-backups-count=14 \
  --enable-point-in-time-recovery \
  --no-assign-ip \
  --enable-private-service-connect \
  --allowed-psc-projects=PROJECT_ID

# 建立資料庫
gcloud sql databases create appdb --instance=prod-postgres

# 範例使用密碼帳號；正式環境也可評估 IAM database authentication
gcloud sql users create appuser \
  --instance=prod-postgres \
  --password="$(openssl rand -base64 32)"

# 建立讀取副本
gcloud sql instances create prod-postgres-replica \
  --master-instance-name=prod-postgres \
  --region=asia-east1 \
  --tier=db-perf-optimized-N-2

結語

Cloud SQL 適合想保留 MySQL、PostgreSQL 或 SQL Server 生態，又不想自行管理主機的團隊。做決定時，先確認版本相容性和 Region，再選 Edition、機型與 HA；接著把網路路徑、Connector、資料庫帳號分開設計，最後用 RPO、RTO 決定備份和 PITR 保留期。

有兩個觀念特別值得帶走：HA standby 不會幫你分攤查詢，讀取擴充要用 read replica；storage auto-increase 也不是完整的自動縮放，容量變大後若要縮小，仍得安排 storage shrink 和停機窗口。把這些取捨在上線前講清楚，比出問題後才補設定容易得多。

官方資料

• Cloud SQL database version policies
• Cloud SQL editions
• High availability
• Connection options
• Cloud SQL Auth Proxy
• Private Service Connect
• Backups overview
• Point-in-time recovery
• Storage shrink
• Read replicas
• Cloud SQL pricing

系列文章

• 上一篇：Cloud Storage 入門
• 下一篇：Cloud Run 入門

資料庫選型系列

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

不確定該選哪個資料庫時，可以再看 GCP 資料庫選型指南。