本頁面提供最佳做法，有助您實現 Cloud SQL 的最佳效能、耐用性和可用性。
如果 Cloud SQL 執行個體發生問題，請在疑難排解期間查看下列事項：
執行個體設定與管理
| 最佳做法 | 更多資訊 |
|---|---|
| 請詳讀並遵守操作指南，確保您的執行個體在 Cloud SQL 服務水準協議的涵蓋範圍內。 | |
| 設定主要執行個體的維護期間，以便控制發生中斷型更新的時間。 | 請參閱維護期間。 |
| 如果您會定期刪除和重新建立執行個體，請使用執行個體 ID 中的時間戳記來提高新執行個體 ID 可用的可能性。 | |
| 前一項作業完成之前，請勿開始進行管理作業。 |
Cloud SQL 執行個體要待到完成前一項作業後，才能接受新的作業要求。如果試圖提前啟動新作業，作業要求會失敗。重新啟動執行個體也包含在內。
Google Cloud 主控台中的執行個體狀態無法反映作業是否正在執行。綠色勾號只代表執行個體的狀態為 |
| 設定儲存空間，以便進行重要資料庫維護作業。 |
如果啟用自動增加儲存空間的執行個體設定已停用，或是已啟用自動增加儲存空間限制，請務必至少保留 20% 的可用空間，以便 Cloud SQL 執行任何重要的資料庫維護作業。 如要接收可用磁碟空間低於 20% 的警報，請為「磁碟使用率」指標建立以指標為基礎的警報政策，並將「門檻位置」設為「高於門檻」，值為 .8。詳情請參閱「建立以指標為基礎的警告政策」。 |
| 避免 CPU 使用率超載。 |
您可以在 Google Cloud 控制台的執行個體詳細資料頁面中，查看執行個體使用的可用 CPU 百分比。詳情請參閱「指標」一文。您也可以建立指標門檻快訊政策，監控 CPU 用量，並在達到指定門檻時收到快訊通知。 為避免 CPU 使用率過高，您可以增加執行個體的 CPU 數量。變更 CPU 需要重新啟動執行個體。如果執行個體已達 CPU 數量上限，您必須將資料庫分割成多個執行個體。 |
| 避免記憶體耗盡。 |
如要查看記憶體耗盡的跡象，請主要使用「用量」指標。為避免記憶體不足錯誤，建議您將這個指標保持在 90% 以下。 您也可以使用 total_usage 指標，查看 Cloud SQL 執行個體使用的可用記憶體百分比，包括資料庫容器使用的記憶體，以及作業系統快取所分配的記憶體。 觀察這兩項指標的差異，即可瞭解程序與作業系統快取使用了多少記憶體。您可以重新利用此快取中的記憶體。 如要預測記憶體不足的問題，請同時查看並解讀這些指標。如果指標顯示過高，表示執行個體的記憶體可能不足。這可能是因為自訂設定、執行個體不敷工作負載需求，或是上述因素的組合所致。 調整 Cloud SQL 執行個體，以增加記憶體容量。 變更執行個體的記憶體大小時，必須重新啟動執行個體。如果執行個體已達到記憶體大小上限，您必須將資料庫分割成多個執行個體。如要進一步瞭解如何在 Google Cloud 控制台中監控這兩項指標，請參閱「指標」一文。 |
安全性
| 最佳做法 | 更多資訊 |
|---|---|
| 偏好使用私人 IP | 除非需要公開 IP 存取權，否則建議使用私人 IP。這有助於盡量減少資料庫的未經授權網路連線。 |
| 避免在授權網路中使用 0.0.0.0/0 | 請勿將 0.0.0.0/0 納入「已授權的網路」，因為這會允許來自全球網際網路的存取權，且不受任何限制。 |
| 避免使用過大的授權網路 | 請勿在授權網路中使用較小的 CIDR 前置字串，因為這會允許來自可能過多主機的存取權。建議 CIDR 前置詞不得小於 /16，最好大於 /19。 |
| 啟用密碼政策 | 使用 MySQL 或 PostgreSQL 執行個體密碼政策，為資料庫執行個體指定適當的密碼政策，避免設定弱密碼、設定到期時間，以及在登入失敗時設定帳戶鎖定。如果您要設定公開 IP 的執行個體，這點就特別重要。 |
資料架構
| 最佳做法 | 更多資訊 |
|---|---|
| 盡可能將大型執行個體分割為較小的執行個體。 | 請盡量使用多個小型 Cloud SQL 執行個體，效果會比使用單個大型的執行個體更好。大型的單體式執行個體在管理上會比多個小型執行個體更困難。 |
應用程式實作
| 最佳做法 | 更多資訊 |
|---|---|
| 使用適合的連線管理做法，例如連線集區和指數輪詢。 | 使用這些技術可改善應用程式的資源運用，也有助於遵守 Cloud SQL 連線限制。如需詳細資訊和程式碼範例，請參閱「管理資料庫連線」一文。 |
| 測試應用程式對維護更新的回應，更新在維護期間隨時可能會發生。 | 請嘗試使用自助式維護功能模擬維護更新。在維護期間，執行個體會在短時間內無法使用，且現有的連線會中斷。測試維護功能的推出作業，有助您進一步瞭解應用程式如何處理預定維護作業，以及系統復原的速度。 |
| 測試應用程式對容錯移轉的回應，容錯移轉隨時可能發生。 | 您可以使用 Google Cloud 控制台、gcloud CLI 或 API 手動啟動容錯移轉。請參閱「啟動容錯移轉」。 |
| 避免進行大量交易。 | 盡量維持小型簡短交易。如果需要更新大型資料庫，請分成多項小型交易進行，而非進行單次的大型交易。 |
| 如果使用的是 Cloud SQL 驗證 Proxy，請務必使用最新版本。 | 請參閱保持 Cloud SQL 驗證 Proxy 為最新版本。 |
資料匯入與匯出
| 最佳做法 | 更多資訊 |
|---|---|
| 加速匯入小型執行個體。 | 針對較小的執行個體，您可以暫時增加執行個體的 CPU 和 RAM，以改善匯入大型資料集時的效能。 |
| 如果您要匯出資料以匯入至 Cloud SQL，請務必採用正確程序。 | 請參閱 從外部代管的資料庫伺服器匯出資料一文。 |
備份與還原
| 最佳做法 | 更多資訊 |
|---|---|
| 使用合適的 Cloud SQL 功能保護您的資料。 |
備份和匯出是提供資料備援和資料保護的兩種方式。這兩種方式可在不同情境下各自提供保護，在健全的資料保護策略中下，兩者相輔相成。 建立備份既輕鬆又快速，能夠將執行個體上的資料還原至你在備份時的狀態。不過備份有一些限制。如果刪除執行個體，也會一併刪除備份。您無法備份單一資料庫或資料表。而且如果執行個體所在的地區無法使用，即使您身在可用的地區，也無法透過備份還原執行個體。 匯出所需的時間較長，因為會在 Cloud Storage 建立外部檔案，讓您用來重新建立資料。即使刪除執行個體，也不會影響到匯出的資料。此外，您只能匯出單一資料庫或資料表，視您選擇的匯出格式而定。 |
| 避免意外刪除執行個體和備份。 | 您在 Google Cloud 控制台或透過 Terraform 建立的 Cloud SQL 執行個體，預設會啟用防止意外刪除功能。 使用 Cloud SQL 中的匯出功能，匯出資料以便進一步保護。搭配使用 Cloud Scheduler 和 REST API，自動管理匯出作業。如要處理更進階的情況，請使用 Cloud Scheduler 搭配 Cloud Run 函式進行自動化。 |
後續步驟
如要進一步瞭解資料庫引擎的一般做法，請參閱：