GCP-108：Cloud SQL 入門——托管關聯式資料庫完全指南

前言

要在雲端跑關聯式資料庫，Cloud SQL 通常是 GCP 上的第一選擇。它是全托管（Full Managed）的，你不用管作業系統、打 patch、排備份，只要建好執行個體、設好連線，剩下就跟操作本地資料庫差不多。

這篇是 GCP 入門系列第 3 課，從零帶你認識 Cloud SQL 的核心概念、定價怎麼算，還有實際怎麼操作。

---

什麼是 Cloud SQL？

Cloud SQL 是 GCP 提供的全托管關聯式資料庫服務（Fully Managed RDBMS），支援三種資料庫引擎：

引擎	支援版本
MySQL	8.0、8.4
PostgreSQL	14、15、16、17、18（18 為最新／預設版）
SQL Server	2017、2019、2022（皆 Standard/Enterprise/Express/Web）、2025（Standard/Enterprise/Express）

所謂「全托管」，就是這些都由 Google 幫你扛：

• 作業系統更新與安全修補
• 資料庫引擎升級（可排程）
• 自動備份
• 儲存空間自動擴充
• 高可用配對（HA）

你要顧的只剩下：Schema、使用者帳號、查詢最佳化、應用程式連線。

---

版本選型建議

MySQL

• 8.4：目前最新長期支援版（LTS），適合新專案；相較 8.0 預設值更安全、移除舊有已棄用功能，並支援 EXPLAIN ANALYZE（自 8.0.18 起）
• 8.0：最廣泛使用版本，生態系相容性最好

MySQL 5.7／5.6 已過社群 EOL，Cloud SQL 仍可運行但已進入付費延伸支援，新專案不建議使用。

PostgreSQL

• 18：最新／預設版（用 gcloud 沒指定版本時就是它），效能與運維工具持續強化
• 17：穩定成熟，支援 MERGE 完整語法、更好的 JSON 路徑查詢
• 16：大量新功能（邏輯複寫增強、並行查詢改善）
• 14、15：舊系統遷移用，14 仍受支援（2027 進入延伸支援）

建議新專案直接用 PostgreSQL 17 或 18

---

執行個體類型（Machine Type）

Cloud SQL 使用 Shared core（共享核心） 和 Dedicated core（專用核心） 兩大類型：

Shared Core（入門/測試用）

類型	vCPU	記憶體	備註
db-f1-micro	0.2	0.6 GB	無 SLA，不適用生產環境
db-g1-small	0.5	1.7 GB	無 SLA，不適用生產環境

⚠️ 重要：db-f1-micro 和 db-g1-small 不提供 SLA，只適合開發、測試、非關鍵工作負載。

Dedicated Core（生產環境）

系列	格式	特性
Enterprise	db-custom-X-Y（含 N4）	標準生產等級，99.95% SLA
Enterprise Plus	db-perf-optimized-N-*	高效能，99.99% SLA，SSD 資料快取（Data Cache，本地 SSD）

Enterprise Plus 適合：

• 低延遲要求（< 1ms）
• 讀取密集型工作負載
• 需要 99.99% SLA 的關鍵系統

---

高可用架構（HA）

Cloud SQL HA 採用**區域內主備（Regional HA）**設計，使用 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）
• 故障切換（Failover）時間：約 60 秒
• 備用節點不對外提供讀取服務（與 RDS Multi-AZ 類似）
• 啟用 HA 後費用約 2 倍（primary + standby）

💡 重點提點

這是最常被新手搞錯、考試也最愛挖的一個坑：HA 的 standby 不能拿來讀。它平常完全閒著，只在 primary 掛掉時頂上去，付了兩倍的錢買的是「可用性」，不是「效能」。如果你發現資料庫讀取卡卡的，想靠開 HA 來分攤——白花錢，問題一點都不會好。要分攤讀取流量得另外建讀取副本（read replica），那才是專門接 SELECT 的角色。記住一句話：HA 求活著，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）

---

連線方式

先講一個容易混淆的點：下面三種方式常被排成「優先序」，但它們其實不是純粹三選一。Auth Proxy（連線代理）解決的是「怎麼安全地驗證並加密這條連線」，PSC（網路拓樸）解決的是「這條連線走哪條私有網路路徑」——不同層次的東西，實務上甚至會疊在一起用。把它們當成「同一道題的三個選項」是新手常見的誤解，看的時候心裡有個底就好。

方式一：Cloud SQL Auth Proxy（推薦）

Cloud SQL Auth Proxy 是 Google 提供的本地代理程式，會用 IAM 驗證幫你開一條加密隧道：

# 下載 Auth Proxy
curl -o cloud-sql-proxy \
  https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.1/cloud-sql-proxy.linux.amd64

# 啟動代理
./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 驗證，不需要開防火牆規則
• 支援 Unix socket（效能更好）

方式二：Private Service Connect（新推薦）

Private Service Connect (PSC) 是現在 Google 最推薦的私有連線方式，用來取代舊的 VPC Peering（Private IP）：

# 建立支援 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 vs. VPC Peering 比較：

特性	Private Service Connect	VPC Peering
路由衝突	無（獨立 IP）	可能衝突
跨專案	支援	複雜
安全性	更高（單向存取）	雙向
建議程度	✅ 推薦	逐漸淘汰

方式三：Public IP + Authorized Networks

設定最簡單，但安全性也最差。你得在「授權網路」裡加上 IP 白名單：

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

⚠️ 生產環境不建議使用 Public IP，除非搭配 Cloud SQL Auth Proxy。

---

使用者與資料庫管理

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

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

# 建立使用者（PostgreSQL，使用 Cloud IAM 驗證）
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

---

備份策略

自動備份（Automated Backups）

# 設定自動備份（每天凌晨 2 點，保留 7 天）
gcloud sql instances patch my-db \
  --backup-start-time=02:00 \
  --retained-backups-count=7

預設行為：

• 每天自動備份
• 保留 7 份（可設定 1~365）
• 存在 Google 管理的儲存空間

隨選備份（On-Demand Backups）

gcloud sql backups create --instance=my-db

時間點還原（Point-in-Time Recovery, PITR）

PITR 讓你還原到任意時間點，不只是「某次備份當下」那個時間點。它能做到這件事，是因為資料庫除了定期快照，還會持續記一份「交易流水帳」（PostgreSQL 叫 WAL、MySQL 叫 binlog——白話講就是把每一筆寫入動作依序記下來的日誌）。還原時系統先還原最近的快照，再把流水帳重播到你指定的那一秒，所以你可以精準還原到「誤刪資料的前一刻」：

# 啟用 PITR（需要先啟用 binlog/WAL）
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）

---

儲存與擴充

儲存設定

gcloud sql instances create my-db \
  --storage-size=20GB \           # 初始儲存大小（最小 10GB）
  --storage-type=SSD \            # SSD（建議）或 HDD
  --storage-auto-increase         # 自動增加儲存（建議啟用）

儲存自動增加（--storage-auto-increase）：

• 當可用空間低於門檻值（約 5 + 容量/25 GB，最大 25GB）時自動擴充
• 每次擴充量等於門檻值（= 5 + 容量/25，最大 25GB），並非固定 25GB 或按比例取較大值
• 注意：只能擴充，不能縮小

💡 重點提點

「只能增不能減」這條，新手很容易輕忽，等帳單來了才有感。打開 --storage-auto-increase 之後，磁碟會自己越長越大，但長上去就回不來了——哪天你刪掉一大批資料想把空間縮回去？做不到，只能整個重建 instance 再搬資料。所以建議勾它（避免半夜被塞爆磁碟導致服務掛掉），但要搭配一條磁碟用量的告警，盯著它別失控長大。儲存費是按你「實際配置的容量」收的，不是按你「用了多少」收的，這點要先有心理準備。

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

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

⚠️ 修改 tier 需要重啟，約有 60 秒停機時間（HA 模式下會自動 failover）

---

讀取副本（Read Replicas）

讀取副本是用來分散讀取負載的：

# 建立讀取副本（同區域）
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）
• 可從副本建立備份（節省 primary 資源）

---

定價模式

Cloud SQL 無免費層，費用組成：

費用項目	說明
執行個體費用	依 vCPU + 記憶體計費，按小時
儲存費用	依每 GB 每月計費，SSD 比 HDD 貴，HA 又比非 HA 貴
備份費用	超過執行個體儲存大小的部分才計費
網路費用	Egress（資料往外傳出的流量）計費，同 Region 內免費

儲存單價會隨 region 和是否啟用 HA 浮動，每隔一陣子也可能調整，這裡就不寫死數字了。要算成本請直接查 Cloud SQL 官方定價頁 並挑你實際要用的 region，那才是準的。

💡 省錢技巧：不用的測試環境記得停機（gcloud sql instances patch --activation-policy NEVER），停機後只收儲存費用。

---

與其他 GCP 資料庫服務比較

服務	類型	適用場景
Cloud SQL	托管 RDBMS	傳統 OLTP 應用，MySQL/PostgreSQL/SQL Server
Cloud Spanner	分散式 RDBMS	全球一致性，水平擴展，高吞吐
AlloyDB	PostgreSQL 相容	高效能 PostgreSQL，交易效能比自建 PostgreSQL 快 4x（官方數據）
Firestore	NoSQL 文件型	行動/Web 應用，彈性 Schema
Bigtable	NoSQL 寬欄型	時序資料、IoT，百萬 QPS

選型決策樹：

需要 SQL？
├─ 是 → 需要水平擴展或全球一致性？
│        ├─ 是 → Cloud Spanner
│        └─ 否 → 需要高效能 PostgreSQL？
│                 ├─ 是 → AlloyDB
│                 └─ 否 → Cloud SQL ✅
└─ 否 → 文件型 → Firestore；時序/大量寫入 → Bigtable

---

ACE 考試重點整理

必背知識點

1. db-f1-micro 和 db-g1-small 無 SLA，不適合生產環境
2. HA 使用 Regional Persistent Disk，將資料以區塊層級同步複寫（block-level synchronous replication）到兩個 Zone 的磁碟；寫入需在兩個 Zone 的磁碟都落盤後才回報 commit
3. 連線方式優先順序：Private Service Connect > Auth Proxy > Public IP
4. **VPC Peering（Private IP）**逐漸被 PSC 取代
5. PITR 需要啟用 --enable-point-in-time-recovery
6. 儲存只能增加，不能縮小
7. 停機後只收儲存費用（activation-policy NEVER）

常見陷阱題

Q：啟用 HA 後效能如何？ A：standby 節點不提供讀取服務，不會提升效能，只提升可用性。要提升效能需另建讀取副本。

Q：讀取副本和 HA standby 有什麼差別？ A：HA standby 用於故障切換（Failover），使用者無法直接連線；讀取副本可接受讀取流量，是不同資源。

Q：要降低讀取延遲，應該怎麼做？ A：建立同區域讀取副本（低延遲）或跨區域讀取副本（就近存取）。

Q：Cloud SQL 有免費方案嗎？ A：沒有。Cloud SQL 從第一個小時就開始計費。

---

實戰範例：建立 PostgreSQL 生產環境執行個體

# 建立 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=$(gcloud config get-value project)

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

# 建立應用程式使用者
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 是 GCP 上最直接的關聯式資料庫選擇，大多數傳統應用場景都罩得住。重點整理：

• 選版本：MySQL 8.0/8.4，PostgreSQL 14-18（新專案直接挑 18），依應用相容性選擇
• 選機型：生產環境用 Enterprise 或 Enterprise Plus，測試才用 db-f1-micro
• HA 架構：Regional Persistent Disk 共享儲存，切換約 60 秒
• 連線：優先 Private Service Connect，其次 Auth Proxy
• 備份：自動備份 + PITR，確保 RTO/RPO 達標

真正上手之後你大概會踩到兩件事：一是想靠 HA 加速讀取，結果發現 standby 根本不給讀；二是隨手開了 storage auto-increase，幾個月後才發現磁碟悄悄長大、又縮不回去。這兩個坑前面都用提點框標出來了，先記著，之後實作會省你不少冤枉路。

下一課 ACE-209：Cloud Pub/Sub 與事件驅動架構，學習如何用訊息佇列解耦微服務。

資料庫選型系列

課程	服務	適合場景
本課 GCP-108	Cloud SQL	中小型 OLTP、傳統 SQL 應用
GCP-112	Firestore	Mobile/Web App、即時同步
GCP-113	Bigtable	PB 級 IoT/時序、低延遲高吞吐
ACE-211	BigQuery	PB 級分析、BI 報表
ACE-213	Spanner	全球規模 OLTP、強一致性
GCP-115	Memorystore	微秒級快取、Session 管理

📖 延伸閱讀：不確定該選哪個資料庫？參考 GCP 資料庫選型完全指南，用決策樹 5 分鐘找到答案。