返回首頁雲端資料庫

雲端資料庫 MySQL 整合指南：從本地遷移到雲端的完整教學

12/13/202525 min 分鐘閱讀

#MySQL#雲端資料庫#資料庫遷移#AWS RDS#GCP Cloud SQL#Azure MySQL#DBA#資料庫管理#雲端架構#技術教學

你的 MySQL 資料庫還跑在公司機房的那台老伺服器上嗎？硬碟快滿了、效能越來越慢、半夜還要擔心當機。這些問題，搬上雲端就能解決大半。

這篇文章會手把手教你如何把 MySQL 遷移到雲端。從選擇平台、規劃遷移、實際操作到上線後的優化，每一步都有詳細說明。不管你是第一次接觸雲端，還是想確認自己的做法對不對，這篇都能幫到你。

延伸閱讀：雲端資料庫完整指南｜了解雲端資料庫的基本概念

插圖：一個流程圖，左側是本地伺服器（顯示 MySQL logo），...

場景描述： 一個流程圖，左側是本地伺服器（顯示 MySQL logo），中間是遷移過程（資料流動的視覺化），右側是雲端平台的資料庫服務。下方有一個時間軸顯示遷移步驟。

視覺重點：

從本地到雲端的遷移過程、MySQL 的識別元素

必須出現的元素：

本地伺服器、MySQL 海豚 logo、雲端資料庫圖示、資料流動箭頭

需要顯示的中文字： 無

顏色調性： MySQL 藍橙色、雲端藍色、白色背景

避免元素： 抽象雲朵圖案、火箭、燈泡

Slug: mysql-database-cloud-migration-workflow

為什麼要將 MySQL 搬到雲端？

雲端 MySQL 的優勢

把 MySQL 搬上雲端，你會得到這些好處：

1. 不用再管硬體 硬碟壞了、記憶體不夠、CPU 撐不住——這些事情都交給雲端廠商處理。你只需要專心在資料庫的使用和優化。

2. 彈性擴展 流量暴增？點幾下滑鼠就能升級規格。促銷活動結束？再降回來。不用提前幾個月規劃採購。

3. 自動備份與災難復原 雲端服務預設就有自動備份，還可以設定跨區域複寫。就算整個機房掛掉，資料也不會丟。

4. 高可用性 Multi-AZ 部署、自動故障轉移，這些在傳統環境要花大錢建置的功能，雲端勾選就有。

5. 省人力成本 不需要專職 DBA 24 小時盯著。雲端廠商的團隊幫你處理底層維運。

適合遷移的時機

這些情況特別適合考慮遷移：

硬體即將到期：與其花錢買新伺服器，不如直接上雲
業務快速成長：需要更彈性的擴展能力
計劃數位轉型：其他系統也要上雲，資料庫一起搬
維運人力不足：沒有專職 DBA，希望減少維運負擔
需要高可用性：業務不容許長時間停機

遷移前的評估要點

遷移不是說搬就搬，先評估這些問題：

1. 資料量有多大？

幾十 GB：遷移相對簡單，停機時間短
幾百 GB：需要規劃，可能要幾小時
TB 級別：需要專業規劃，考慮持續複寫方案

2. 能接受多長的停機時間？

可以停機幾小時：用 mysqldump 最簡單
只能停機幾分鐘：需要用複寫方案
完全不能停機：需要更複雜的架構

3. 應用程式需要改嗎？

連線字串一定要改
如果用了 MySQL 特有功能，要確認雲端版本支援
儲存過程、觸發器要測試

4. 預算夠嗎？

雲端每月費用 vs 現在的硬體攤提 + 人力成本
別忘了網路傳輸費用

三大平台的 MySQL 服務比較

三大雲端平台都有 MySQL 託管服務。詳細比較：AWS、GCP、Azure 資料庫完整比較

AWS RDS for MySQL

AWS 的 MySQL 服務最成熟，選擇最多。

項目	內容
MySQL 版本	5.7、8.0
最大儲存	64 TB
最大連線數	16,000（依規格）
讀取副本	最多 15 個
Multi-AZ	✅
自動備份	最多 35 天

優點：

執行個體類型選擇最多
Performance Insights 效能分析很強
Aurora MySQL 版本效能更好

缺點：

價格相對較高
設定選項多，新手容易迷路

適合： 已經在用 AWS 的企業、需要最大彈性的場景

GCP Cloud SQL for MySQL

Google Cloud 的 MySQL 服務簡單易用。詳細教學：Google 雲端資料庫完整教學

項目	內容
MySQL 版本	5.7、8.0
最大儲存	64 TB
最大連線數	4,000（依規格）
讀取副本	最多 10 個
高可用性	✅
自動備份	最多 365 天

優點：

介面簡潔，容易上手
備份保留期限最長（365 天）
台灣有資料中心

缺點：

連線數上限較低
進階功能比 AWS 少

適合： 新創公司、需要台灣資料落地的企業

Azure Database for MySQL

微軟 Azure 的 MySQL 服務，企業導向。

項目	內容
MySQL 版本	5.7、8.0
最大儲存	16 TB
最大連線數	5,000（依規格）
讀取副本	最多 10 個
高可用性	✅
自動備份	最多 35 天

優點：

與 Azure 其他服務整合好
Flexible Server 選項彈性大
台灣有資料中心

缺點：

儲存上限較小（16 TB）
社群資源比 AWS 少

適合： Microsoft 生態系企業、有 EA 合約的組織

功能與價格比較表

比較項目	AWS RDS	GCP Cloud SQL	Azure MySQL
最低月費（估）	~$15	~$10	~$12
免費額度	750 小時/月（12 個月）	無（有 $300 試用金）	750 小時（12 個月）
台灣資料中心	❌	✅	✅
Serverless 選項	Aurora Serverless	預覽中	Flexible Server

插圖：三欄式的比較卡片，分別代表 AWS RDS、GCP Clou...

場景描述： 三欄式的比較卡片，分別代表 AWS RDS、GCP Cloud SQL、Azure MySQL。每張卡片顯示關鍵規格數字和優缺點摘要。

視覺重點：

三個平台的清晰比較、關鍵數字的突出

必須出現的元素：

三個平台的 logo 或識別色、MySQL logo、關鍵規格數字

需要顯示的中文字： 無

顏色調性： AWS 橙色、GCP 藍綠色、Azure 藍紫色

避免元素： 過於複雜的圖表、抽象圖形

Slug: aws-gcp-azure-mysql-service-comparison

MySQL 雲端遷移步驟

實際動手遷移了。這邊以 GCP Cloud SQL 為例，其他平台流程類似。

Step 1：評估現有資料庫

遷移前先搞清楚現況：

# 查看資料庫大小
SELECT
    table_schema AS 'Database',
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)'
FROM information_schema.tables
GROUP BY table_schema;

# 查看 MySQL 版本
SELECT VERSION();

# 查看字元集設定
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

# 查看目前連線數
SHOW STATUS LIKE 'Max_used_connections';

記錄這些資訊：

資料庫總大小
MySQL 版本
字元集（charset）和排序規則（collation）
最大同時連線數
使用的引擎（InnoDB、MyISAM）

Step 2：選擇目標平台與規格

根據評估結果選擇：

選擇平台： 看你公司用哪個雲端、預算、是否需要台灣資料中心

選擇規格：

vCPU：比現有伺服器略大，留點餘裕
記憶體：至少和現在一樣，建議多一點
儲存：現有資料量 x 2，預留成長空間
儲存類型：選 SSD，效能差很多

選擇區域：

離用戶近的區域（台灣用戶選 asia-east1）
考慮是否需要高可用性（Multi-AZ）

Step 3：建立雲端 MySQL 執行個體

以 GCP Cloud SQL 為例：

登入 GCP Console
- 前往 console.cloud.google.com
- 選擇或建立專案
建立 Cloud SQL 執行個體
- 搜尋「Cloud SQL」
- 點選「建立執行個體」
- 選擇「MySQL」

設定執行個體

執行個體 ID：my-mysql-instance（自訂）
密碼：設定 root 密碼
MySQL 版本：選擇和來源相同的版本
區域：asia-east1（台灣）
可用區：單一或多個（高可用性）

設定機器規格

vCPU：依需求選擇
記憶體：依需求選擇
儲存類型：SSD
儲存容量：依需求設定
啟用自動增加儲存空間：建議開啟

設定連線

公開 IP：依需求（建議用私有 IP）
授權網路：加入你的 IP

點選「建立」，等待幾分鐘

Step 4：資料遷移方法

有幾種方式可以遷移資料：

方法一：mysqldump（適合小型資料庫）

最簡單直接，適合幾十 GB 以下的資料庫。

# 在來源伺服器匯出
mysqldump -u root -p \
  --single-transaction \
  --routines \
  --triggers \
  --databases your_database > backup.sql

# 匯入到雲端 MySQL
mysql -h [CLOUD_SQL_IP] -u root -p your_database < backup.sql

方法二：Database Migration Service（適合大型資料庫）

三大平台都有遷移服務：

AWS：Database Migration Service (DMS)
GCP：Database Migration Service
Azure：Azure Database Migration Service

這些服務支援持續複寫，可以最小化停機時間。

方法三：MySQL Replication（適合零停機需求）

設定主從複寫，讓雲端 MySQL 成為現有資料庫的 replica：

-- 在來源伺服器設定
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%' IDENTIFIED BY 'password';

-- 在雲端 MySQL 設定
CHANGE MASTER TO
  MASTER_HOST='source_ip',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=123;

START SLAVE;

同步完成後，切換應用程式連線，停掉複寫即可。

Step 5：應用程式連線設定

資料遷移完成後，更新應用程式的連線設定：

連線字串範例：

# Python (mysql-connector-python)
import mysql.connector

conn = mysql.connector.connect(
    host="[CLOUD_SQL_IP]",
    user="your_user",
    password="your_password",
    database="your_database",
    ssl_ca="server-ca.pem",
    ssl_cert="client-cert.pem",
    ssl_key="client-key.pem"
)

// Node.js (mysql2)
const mysql = require('mysql2');

const connection = mysql.createConnection({
  host: '[CLOUD_SQL_IP]',
  user: 'your_user',
  password: 'your_password',
  database: 'your_database',
  ssl: {
    ca: fs.readFileSync('server-ca.pem'),
    cert: fs.readFileSync('client-cert.pem'),
    key: fs.readFileSync('client-key.pem')
  }
});

GCP Cloud SQL Proxy（推薦）：

用 Cloud SQL Proxy 更安全，不需要設定公開 IP：

# 下載並執行 Cloud SQL Proxy
./cloud-sql-proxy --port 3306 PROJECT_ID:REGION:INSTANCE_NAME

# 應用程式連線到 localhost:3306 即可

Step 6：測試與驗證

上線前一定要充分測試：

1. 資料完整性檢查

-- 比較來源和目標的資料筆數
SELECT COUNT(*) FROM your_table;

-- 檢查 checksum
CHECKSUM TABLE your_table;

2. 效能測試

# 用 sysbench 做基準測試
sysbench oltp_read_write \
  --mysql-host=[CLOUD_SQL_IP] \
  --mysql-user=root \
  --mysql-password=xxx \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 \
  prepare

sysbench oltp_read_write \
  --mysql-host=[CLOUD_SQL_IP] \
  --mysql-user=root \
  --mysql-password=xxx \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 \
  --threads=16 \
  --time=60 \
  run

3. 應用程式測試

在測試環境連接雲端資料庫
跑完整的功能測試
做負載測試，確認能承受預期流量

MySQL 遷移看起來很複雜？ 其實有經驗的話可以很順利。預約遷移諮詢，讓我們幫你規劃遷移策略。

雲端 MySQL 最佳實踐

搬上雲端後，這些設定和習慣能讓你的 MySQL 跑得更好。

效能調校技巧

1. 調整緩衝池大小

InnoDB buffer pool 是效能關鍵。雲端服務通常會自動設定，但可以檢查：

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

建議設為可用記憶體的 70-80%。

2. 優化查詢

用 EXPLAIN 分析慢查詢：

EXPLAIN SELECT * FROM orders WHERE customer_id = 123;

確保常用查詢有用到索引。

3. 啟用查詢快取（MySQL 5.7）

MySQL 8.0 已移除查詢快取，但 5.7 還可以用：

SET GLOBAL query_cache_type = ON;
SET GLOBAL query_cache_size = 67108864;  -- 64MB

4. 連線池設定

應用程式端使用連線池，避免頻繁建立連線：

# Python SQLAlchemy 連線池範例
from sqlalchemy import create_engine

engine = create_engine(
    'mysql+pymysql://user:pass@host/db',
    pool_size=10,
    max_overflow=20,
    pool_recycle=3600
)

安全性設定（SSL、IAM、防火牆）

1. 強制 SSL 連線

-- 建立只允許 SSL 連線的用戶
CREATE USER 'app_user'@'%' REQUIRE SSL;
GRANT ALL PRIVILEGES ON your_db.* TO 'app_user'@'%';

2. 最小權限原則

不要所有應用都用 root：

-- 建立只有必要權限的用戶
CREATE USER 'readonly'@'%' IDENTIFIED BY 'password';
GRANT SELECT ON your_db.* TO 'readonly'@'%';

CREATE USER 'app'@'%' IDENTIFIED BY 'password';
GRANT SELECT, INSERT, UPDATE, DELETE ON your_db.* TO 'app'@'%';

3. 網路存取控制

盡量用私有 IP，不開公開 IP
如果要開公開 IP，只允許特定 IP 存取
用 VPC peering 連接其他服務

備份與災難復原策略

1. 自動備份設定

三大平台都有自動備份功能：

設定每日備份時間（選離峰時段）
保留天數至少 7 天，重要系統建議 30 天
定期測試還原，確保備份能用

2. 時間點復原（PITR）

如果誤刪資料，可以還原到特定時間點：

# GCP 範例
gcloud sql instances clone SOURCE_INSTANCE TARGET_INSTANCE \
  --point-in-time '2025-01-15T10:00:00.000Z'

3. 跨區域備份

重要系統建議啟用跨區域備份或讀取副本，防止整個區域故障。

監控與告警設定

1. 關鍵指標監控

這些指標要設定告警：

CPU 使用率 > 80%
記憶體使用率 > 85%
儲存空間使用率 > 80%
連線數接近上限
複寫延遲（如果有 replica）

2. 慢查詢日誌

啟用慢查詢日誌，找出需要優化的 SQL：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;  -- 超過 2 秒算慢查詢

3. 使用雲端監控工具

AWS：CloudWatch + Performance Insights
GCP：Cloud Monitoring + Cloud SQL Insights
Azure：Azure Monitor + Query Performance Insight

插圖：一個資料庫監控儀表板介面，顯示 CPU、記憶體、連線數、查詢...

場景描述： 一個資料庫監控儀表板介面，顯示 CPU、記憶體、連線數、查詢效能等關鍵指標。有圖表、數字和告警狀態。

視覺重點：

監控介面的專業呈現、關鍵指標的視覺化

必須出現的元素：

折線圖、數字指標、告警燈號、時間軸

需要顯示的中文字： 無

顏色調性： 深色背景的儀表板風格、綠色正常、紅色告警

避免元素： 過於簡化的圖表、卡通風格

Slug: mysql-monitoring-dashboard-interface

常見問題與解決方案

連線問題排查

問題：連不上雲端 MySQL

檢查清單：

IP 白名單設定了嗎？
防火牆有開 3306 port 嗎？
使用者帳號設定正確嗎？
SSL 憑證路徑對嗎？

# 測試連線
mysql -h [CLOUD_SQL_IP] -u root -p --ssl-mode=REQUIRED

# 如果連不上，先測試網路
telnet [CLOUD_SQL_IP] 3306

問題：SSL 憑證錯誤

# 重新下載憑證
# GCP
gcloud sql ssl client-certs create CLIENT_CERT_NAME \
  --instance=INSTANCE_NAME

# 確認憑證路徑正確
ls -la /path/to/certs/

效能問題診斷

問題：查詢變慢了

-- 查看目前執行中的查詢
SHOW FULL PROCESSLIST;

-- 查看哪些查詢最慢
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

-- 檢查是否有鎖等待
SHOW ENGINE INNODB STATUS;

問題：連線數爆滿

-- 查看目前連線數
SHOW STATUS LIKE 'Threads_connected';

-- 查看最大連線數設定
SHOW VARIABLES LIKE 'max_connections';

-- 查看各用戶連線數
SELECT user, host, COUNT(*) as connections
FROM information_schema.processlist
GROUP BY user, host;

解決方案：

應用程式端使用連線池
升級執行個體規格
檢查是否有連線洩漏

成本優化建議

1. 選對規格

不要一開始就選最大規格。先用小的，監控幾週再決定是否升級。

2. 用承諾使用折扣

確定長期使用的話，買 1 年或 3 年承諾可以省 30-50%。

3. 開發環境省錢

開發環境用最小規格
下班時間可以停止執行個體（注意：停止仍收儲存費）
測試完就刪掉，不要放著不管

4. 監控閒置資源

定期檢查有沒有沒在用的執行個體、快照、備份。

免費 MySQL 雲端選項

預算有限？這些免費方案可以考慮。詳細清單：免費 MySQL 雲端方案清單

PlanetScale 免費方案

項目	免費額度
儲存空間	5 GB
讀取次數	10 億次/月
寫入次數	1,000 萬次/月
分支	2 個（1 production + 1 development）

PlanetScale 是 MySQL 相容的 serverless 資料庫，免費額度很大方。缺點是不支援外鍵約束。

三大平台免費額度

平台	免費內容	期限
AWS RDS	db.t2.micro 750 小時/月	12 個月
GCP Cloud SQL	無免費（有 $300 試用金）	試用金 90 天
Azure MySQL	750 小時/月	12 個月

AWS 和 Azure 的免費額度是新帳號前 12 個月，之後就要付費。GCP 沒有免費 Cloud SQL，但 $300 試用金可以撐一陣子。

常見問題 FAQ

現有的 MySQL 查詢可以直接用嗎？

大部分可以。雲端 MySQL 用的是標準 MySQL 引擎，SQL 語法相容。但要注意：

確認 MySQL 版本相同（5.7 或 8.0）
某些系統變數可能被限制修改
部分儲存過程可能需要調整權限

雲端 MySQL 效能會比較好嗎？

不一定。效能取決於：

你選的規格（vCPU、記憶體）
儲存類型（SSD vs HDD）
網路延遲（應用程式和資料庫的距離）

同樣規格的話，效能應該差不多。雲端的優勢是可以快速升級規格。

遷移過程會中斷服務嗎？

看你選哪種方式：

mysqldump：需要停機，時間取決於資料量
複寫方案：可以最小化停機，只在切換時短暫中斷
Database Migration Service：支援持續複寫，停機時間最短

對於生產環境，建議用複寫方案或 DMS。

遷移後連線字串怎麼改？

主要改這幾個：

Host：改成雲端 MySQL 的 IP 或域名
Port：通常還是 3306
SSL：雲端通常強制 SSL，要加上憑證設定
連線池設定：可能需要調整

結論

把 MySQL 搬到雲端不難，但需要妥善規劃。

遷移檢查清單

重點回顧

選對平台：看你用哪個雲端生態系、是否需要台灣資料落地
選對遷移方式：小資料庫用 mysqldump，大資料庫用 DMS 或複寫
做好測試：上線前一定要測完整性和效能
設定監控：上線後持續監控，及早發現問題

想換平台又怕麻煩？

MySQL 雲端遷移涉及很多細節：

選哪個平台最適合？
遷移過程要停機多久？
費用怎麼估算？
遷移後效能會變好還是變差？

CloudInsight 雲端遷移諮詢 可以幫你：

✅ 遷移評估：分析現有資料庫，評估遷移可行性和風險 ✅ 平台推薦：根據你的需求，推薦最適合的雲端平台 ✅ 成本試算：估算遷移成本和每月營運費用 ✅ 遷移規劃：制定詳細的遷移計畫，最小化停機時間 ✅ 上線支援：遷移過程全程協助，確保順利上線

我們有豐富的 MySQL 雲端遷移經驗，從評估到上線全程協助。

預約遷移諮詢

點我預約 30 分鐘免費諮詢

不管你是第一次遷移還是想優化現有架構，我們都能給你專業建議。

參考資料

AWS RDS for MySQL Documentation
Google Cloud SQL for MySQL Documentation
Azure Database for MySQL Documentation
MySQL 8.0 Reference Manual
Percona - MySQL Performance Tuning
PlanetScale Documentation

需要專業的雲端建議？

無論您正在評估雲平台、優化現有架構，或尋找節費方案，我們都能提供協助

預約免費諮詢

雲端資料庫

雲端資料庫是什麼？2025完整指南｜免費方案、平台比較、建立教學

完整解析雲端資料庫的定義、優缺點與應用場景。比較 AWS、GCP、Azure 三大平台，推薦免費方案，手把手教你建立第一個雲端資料庫。

雲端資料庫

Google 雲端資料庫入門：Firebase 與 Cloud SQL 完整教學

完整介紹 Google Cloud 資料庫服務，包含 Firebase Realtime Database、Firestore、Cloud SQL 的使用教學，從免費方案到企業級應用一次搞懂。

雲端資料庫

2025 免費雲端資料庫完整清單｜7 個適合新手的免費方案推薦

精選 7 個免費雲端資料庫方案，包含 Firebase、PlanetScale、Supabase 等，附詳細免費額度比較表，幫你找到最適合的免費方案。

雲端資料庫 MySQL 整合指南：從本地遷移到雲端的完整教學

為什麼要將 MySQL 搬到雲端？

雲端 MySQL 的優勢

適合遷移的時機

遷移前的評估要點

三大平台的 MySQL 服務比較

AWS RDS for MySQL

GCP Cloud SQL for MySQL

Azure Database for MySQL

功能與價格比較表

MySQL 雲端遷移步驟

Step 1：評估現有資料庫

Step 2：選擇目標平台與規格

Step 3：建立雲端 MySQL 執行個體

Step 4：資料遷移方法

Step 5：應用程式連線設定

Step 6：測試與驗證

雲端 MySQL 最佳實踐

效能調校技巧

安全性設定（SSL、IAM、防火牆）

備份與災難復原策略

監控與告警設定

常見問題與解決方案

連線問題排查

效能問題診斷

成本優化建議

免費 MySQL 雲端選項

PlanetScale 免費方案

三大平台免費額度

常見問題 FAQ

現有的 MySQL 查詢可以直接用嗎？

雲端 MySQL 效能會比較好嗎？

遷移過程會中斷服務嗎？

遷移後連線字串怎麼改？

結論

遷移檢查清單

重點回顧

想換平台又怕麻煩？

預約遷移諮詢

延伸閱讀

參考資料

需要專業的雲端建議？

相關文章

雲端資料庫是什麼？2025完整指南｜免費方案、平台比較、建立教學

Google 雲端資料庫入門：Firebase 與 Cloud SQL 完整教學

2025 免費雲端資料庫完整清單｜7 個適合新手的免費方案推薦