設定 MySQL 適用的 Cloud SQL 執行個體的最佳做法
雖然您可以在自己的實體機器上手動部署 MySQL，甚至在虛擬機器上自行選擇並自行管理，但越來越受歡迎的選擇是使用雲端服務供應商提供的代管服務，這是因為服務供應商可處理 MySQL 的許多營運事宜。
相關文章
最佳做法
MySQL 適用的 Cloud SQL 是一項全代管資料庫服務，可協助您在 Google Cloud 中設定、維護及管理 MySQL 關聯資料庫。當您準備好建立 MySQL 適用的 Cloud SQL 執行個體時，可以選擇下列幾種方式，包括 UI 控制台、gcloud CLI、Terraform 和 REST API。您可以遵守這些說明文件來詳細瞭解這些路徑，但本文的目的，將會使用使用者介面進行說明；我們將介紹設定執行個體的各種最佳做法。
執行個體資訊
選用高強度密碼
這是預設 “root”@”%” 資料庫使用者的密碼，將與執行個體一併建立。如要保留超級使用者為管理員使用者，請務必在這裡選取高強度密碼。基於安全考量，建議您使用不常見的管理員使用者來取代 "root"。請參閱「管理資料庫使用者」一節。
建立執行個體層級密碼政策
密碼政策功能則能強化資料庫安全性。可讓您設定密碼長度、複雜度、到期時間和受限制的重複使用等政策。詳情請參閱強化 MySQL 執行個體一文。
資料庫版本
考慮採用 8.0 版，以提升效能
Cloud SQL MySQL 支援多個 8.0 子版本，目前 v8.0.26 為預設版本。8.0 版的預設版本與 5.7 版和 5.6 版相比，採用多種機器類型的基準測試可帶來更好的查詢總處理量。
請勿將實際工作環境中的執行個體用於最新的正式發布版本
儘管 Oracle 和 Cloud SQL 進行了測試工作，但 MySQL 的重新整理版本尚未經過複雜的全面實際測試。因此，建議您讓實際工作環境執行個體保持穩定版，並使用開發與測試執行個體，測試 MySQL 適用的 Cloud SQL 最新子版本升級作業。
高可用性
為您的實際工作環境執行個體設定多個可用區
MySQL 適用的 Cloud SQL 可以自動容錯移轉至第二個可用區做為高可用性解決方案，藉此提供區域性可用性。為提高可用性，請為實際工作環境執行個體設定多個可用區選項，以便自動取得每日備份和時間點復原 (詳情請參閱「備份排程」一節)。
機器類型
評估目前的 CPU/記憶體用量，做出明智的遷移決策
將現有執行個體遷移至 Cloud SQL 時，您目前的工作負載可協助您選擇適當的 VM 大小。
- CPU：在正常工作負載條件下，您的 CPU 使用率為何？尖峰工作負載呢？執行個體是受到 CPU 限制還是 I/O 限制？如果使用者和/或系統的 CPU 百分比相對較高，表示是受到 CPU 限制的工作負載。如果 I/O 的百分比相對較高，表示是受到 I/O 限制的工作負載。
- 記憶體：同樣地，執行個體的一般記憶體用量多少？尖峰用量是多少？
例如，供 MySQL 適用的 Cloud SQL 使用 1 個 vCPU，最多可支援 6.5 GB 的記憶體。
規劃 CPU 和記憶體 20% 至 50% 的額外空間
即使是一般穩定的執行個體，請規劃至少 20% 的額外空間供 CPU 和記憶體來吸收意外高峰。這對持續成長的企業來說更是重要，建議增加 50%。
Cloud SQL 可讓您輕鬆升級機器類型。提醒您，升級作業有停機時間。
自訂儲存空間
使用 SSD 來提高資料庫效能
MySQL 適用的 Cloud SQL 提供經濟實惠的 HDD 儲存空間方案，但如果您需要高效能資料庫，請移至 SSD 選項。以下是 I/O 效能的比較。
在儲存空間容量方面，規劃效能與成本之間的平衡
磁碟 IOPS 和總處理量與永久磁碟大小相關聯。容量越大，在執行個體限制內就享有更多 IOPS 和總處理量。
對 SSD 來說，可用區和區域設定會影響效能。詳情請參閱可用區性與區域性 SSD 效能資料。如果您選取多個可用區的可用性，請參閱區域性 SSD 效能資料。簡單來說，每 GB 的讀取和寫入 IOPS 為30，總處理量則為每 GB 0.48 MB。使用區域 SSD 時，效能資料相似，但每個執行個體的寫入 IOPS 和寫入總處理量都較低。
請注意，Cloud SQL 執行個體的支援儲存空間大小上限為 64 TB。
啟用自動增加儲存空間並監控磁碟容量擴充程度
Cloud SQL 具備自動增加儲存空間的功能，可避免執行個體耗盡磁碟空間 (OOD)。啟用這項功能後，系統每隔 30 秒會檢查一次儲存空間，並視需要增加額外的儲存空間容量。
這項功能可防範 OOD，但增加的容量一經設定即無法變更，而且執行個體一經設定即無法縮減。請先設定磁碟大小快訊，以便管理和規劃儲存空間容量。
熟悉加密選項
Cloud SQL 預設會為靜態資料加密。不過，如果更符合您的需求，則可選擇使用客戶自行管理的加密金鑰 (CMEK) 而非預設的 Google 代管的金鑰。
設定連線
評估私人 IP 與公開 IP 之間的取捨
私人和公開 IP 是指網路中裝置使用的位址類型。與公開 IP 相比，私人 IP 可加強網路安全性並縮短網路延遲時間。不過，私人 IP 需要額外的 API 和 IAM 設定，因此有時您也需要公開 IP。如果您知道需要使用公開 IP 但想提升安全性，可以選擇要求使用授權網路或使用 Cloud SQL 驗證 Proxy。
考慮使用 Cloud SQL 驗證 Proxy 建立安全連線
Cloud SQL 驗證 Proxy 提供安全的方式存取 Cloud SQL 執行個體，而非設定 SSL 或授權網路。應用程式會進行通訊至本機環境中執行的驗證 Proxy 用戶端，並使用安全的通道與 Cloud SQL 執行個體上的 Proxy 伺服器進行通訊。
設定備份時間表和保留時間
啟用備份與時間點復原功能，並查看資料保留政策
定期資料備份與可驗證的資料復原對於健康的資料庫管理至關重要。在資料損毀或非預期資料作業等情況中，這些做法都非常重要，但無論是哪種情況，都無法因高可用性而緩解。
Cloud SQL 提供自動備份、備份驗證和時間點復原 (PITR)。這些預設為啟用，且為具有多個可用區的執行個體所需。系統每天都會自動備份，預設保留政策則是 7 份備份副本和 7 天二進位檔記錄檔 (PITR 所需)。您可以在「進階選項」部分中調整資料保留政策。
設定資料庫旗標
資料庫旗標是前往 my.cnf 檔案的伺服器設定。清單中具有可配置的資料庫旗標和某些不可配置的代管旗標。建議您查看資料庫標記，並在建立執行個體時將其設定為適當的值。由於部分資料庫旗標並非動態，因此變更這些旗標會觸發執行個體重新啟動。
查看 character_set_server
在 MySQL 適用的 Cloud SQL 執行個體中，v5.6 與 v5.7 的預設 character_set_server 為 utf8，在 v8.0 上則為 utf8mb4。character_set_server 會將 character_set_client、character_set_connection、character_set_database 和 character_set_results 設為相同值。如果是 character_set_system，在 v8.0 上預設為 utf8mb3。
如果您要遷移執行個體，且目前的設定使用不同的字元集 (例如 latin1)，請務必在新執行個體上明確設定 character_set_server。
查看 time_zone
時區的預設值為 system_time_zone，也就是世界標準時間。如要使用其他 time_zone，請透過 default_time_zone 設定。這個標記使用兩種格式：時區偏移 (例如 +08:00) 和時區名稱 (例如 America/Los_Angeles)。時區以時區名稱定義後，系統會自動調整為日光節約時間 (如有相關)。default_time_zone 旗標並非動態，因此必須重新啟動資料庫執行個體才能進行變更。
啟用慢速查詢記錄
slow_query_log 預設為關閉，強烈建議您啟用慢速查詢記錄，並將 long_query_time 設為適合應用程式的門檻。慢速查詢記錄有助於擷取長時間執行的查詢進行分析及最佳化。這些資訊不僅會協助處理個別查詢，還能針對未預期的工作負載進行整體伺服器處理量和回溯分析。
這是 InnoDB 效能最有效的設定。可在記憶體中緩衝的資料越多，伺服器效能就越高。同時，需要為全球緩衝區和每個執行緒動態緩衝區保留足夠的記憶體。
在 Cloud SQL 中，innodb_buffer_pool_size 旗標的預設值、允許的下限值與允許的上限值皆取決於執行個體的記憶體，詳情請參閱說明文件。
好的 innodb_buffer_pool_size 不一定要包含所有資料，而是經常存取的資料。反映緩衝區集區效率的狀態變數為 Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests。Innodb_buffer_pool_read_requests 是邏輯讀取要求的數量，而 Innodb_buffer_pool_reads 是緩衝區不符合的邏輯讀取次數，就必須從磁碟讀取。在理想情況下，資料完全位於緩衝集區中，Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests 的比率將接近零。監控這些變數可瞭解 InnoDB 緩衝區集區效率。如果 innodb_buffer_pool_size 已達到允許的最大值，緩衝集區效率不佳，且應用程式發生查詢效能問題，請考慮將執行個體升級至較高的記憶體容量。
這個變數在 MySQL v5.7 和 v8.0 中會變成動態，而在 v5.6 中，進行變更將需要重新啟動執行個體。
在 8.0.30 之前，innodb_log_file_size 和 innodb_log_files_in_group 並非動態，且變更 innodb_log_file_size 需要乾淨關機作業。在 8.0.30 版，推出 innodb_redo_log_capacity 以取代 innodb_log_file_size 和 innodb_log_files_in_group。
MySQL 適用的 Cloud SQL 執行個體已設定 innodb_log_file_size=512MB、innodb_log_files_in_group=2 (或 innodb_redo_log_capacity=1GB)。如此一來，InnoDB 就能在緩衝區中保留更多變更，而不會同步到磁碟，藉此提升伺服器效能。大型重做記錄檔的缺點是增加當機的復原時間。根據執行個體的高可用性需求和設定，這項決策需要在效能和可用性之間取得平衡。
一般來說，我們建議，重做的記錄檔容量要足以容納一個小時的寫入活動。衡量的一個方法是全天觀測 Innodb_os_log_written 並確保 innodb_log_file_size * innodb_log_files_in_group 的大小足夠用於尖峰觀測的時間。
在 MySQL v5.6 和 v5.7 中，innodb_log_buffer_size 不是動態的，且需要重新啟動執行個體才能變更。因此，最好在初始化時進行設定。
當 innodb_log_buffer_size 大到可以包含整筆交易時，在交易執行期間不會另外清除磁碟。根據預設，innodb_log_buffer_size 設定為 16MB，通常就夠了。不過，如要瞭解大型交易是否需要更大的緩衝區，請在發出大型交易時監控 Innodb_log_waits 狀態變數。如果 innodb_log_buffer_size 太小且需要等待清除，Innodb_log_waits 會增加 1。
隨時調整動態變數
部分效能相關資料庫旗標是動態的，例如table_open_cache、thread_cache_size。您最好先從適合的大小開始，但是建議您視情況建立測量並進行調整。
table_open_cache 用於開放式資料表的數量。有足夠的快取有助於縮短資料表開啟時間，進而提高查詢效能。狀態變數 Opened_tables 會顯示已開啟的資料表數量。如果 Opened_tables 持續成長，請考慮提高 table_open_cache。
thread_cache_size 用於快取執行緒，以便在用戶端中斷連線後重複使用。如果執行個體預期需要同時有大量新連線，請設定較大的大小。狀態變數比率 Threads_created 與連線數的比率表示執行緒快取的效率。低比率則較佳。
對每個執行緒記憶體旗標最好進行較保守的設定
每個執行緒的記憶體緩衝區都會影響查詢效能，例如 tmp_table_size、max_heap_table_size、join_buffer_size、sort_buffer_size 等。這些變數具有全域和工作階段範圍。全域範圍會為所有新連線設定每個執行緒值，而工作階段範圍則適用於目前工作階段的後續查詢。這類設定的記憶體較大，可提高查詢效能。然而，由於其是動態的，且針對每個執行緒分配一或多個，因此可能導致記憶體不足 (OOM) 的情況。
建議針對全域值使用中度數值，並在特定工作階段保留較大的數字，以受到控管的方式獲得更好的效能。
考慮 performance_schema
在 MySQL 8.0.26 版之前，performance_schema 預設為關閉，需要重新啟動才能啟用。performance_schema 可以啟用多種檢測功能，並提供豐富的資料來分析伺服器作業，同時帶來效能和記憶體成本。預設檢測作業會產生約 5% 的效能下降，而且會隨著更多檢測作業增加。工作負載的基準檢測，因為記憶體用量可能會增加至 1 GB 以上。您可以在 memory_summary_global_by_event_name 資料表中觀察這個記憶體用量。
管理資料庫使用者
建立 Cloud SQL 執行個體之後，資料庫中還有一個 ‘root’@’%’ 使用者。您可能需要建立其他資料庫使用者。
限制使用者存取必要作業
請務必限制使用者對於最低權限的存取。
透過 MySQL CLI 建立使用者時，您必須明確授予權限。
透過 Cloud 控制台建立使用者時，使用者會具有與 ‘root’@’%’ 使用者相同的權限。在 MySQL v5.6 和 v5.7 中，預設權限包括所有授予授權選項的權限 (SUPER 和 FILE 權限除外)。在第 8.0 版中，使用者俱備動態權限；雖然 SUPER 和 FILE 權限仍受到限制，但使用者擁有更多管理員角色 (例如 APPLICATION_PASSWORD_ADMIN、CONNECTION_ADMIN、ROLE_ADMIN、SET_USER_ID 和 XA_RECOVER_ADMIN)。您將透過 MySQL CLI 撤銷任何不必要的權限。在 v8.0 執行個體上，partial_revokes 變數已啟用。
考慮將 ‘root’@’%’ 改為特定管理員使用者
‘root’@’%’ 使用者是預設且最熱門的超級使用者，因此常遭駭客鎖定。我們建議您建立與 ‘root’@’%’ 使用者相同的權限組合，然後建立自己的管理員使用者，然後再替換使用者，藉此提升安全性。
設定監控功能
請務必監控及追蹤資料庫作業和系統資源的各方面事項。這項功能可讓您查看並分析執行個體的長期運作狀態，這也有助於規劃資源。
- Cloud 控制台總覽頁面提供核心指標清單。
- Cloud Monitoring 提供其他指標。您可以為資料庫執行個體建立含有所選指標的資訊主頁。在 Cloud 控制台的導覽選單左上方，依序選擇「OPERATIONS」-->「Monitoring」，即可使用 Cloud Monitoring。
- 使用 Cloud SQL 中的查詢洞察，來查詢效能分析。其總覽區段會顯示按資料庫、使用者或用戶端位址切割的 CPU 負載。系統也會進一步細分 CPU 用量，以顯示 I/O 等待與鎖定等待時間。並依查詢摘要列出熱門查詢。您可以針對各個查詢摘要，查看掃描及傳回的平均執行時間、查詢數和平均資料列數。這些指標有助於識別需要最佳化的熱點及查詢。
- 您還可以利用自製的監控工具和/或第三方工具來補充上述資訊。主要目標是瞭解影響伺服器和查詢最佳化及疑難排解的資料庫作業。
設定快訊功能
適當的快訊是伺服器健康狀態的重要一環。可協助您避免因 CPU 飽和度而中斷服務，例如記憶體不足 (OOM) 或系統停擺。
如果您使用 Cloud Monitoring，就可以建立指標型快訊。詳情請參閱說明文件。
如果您使用其他監控工具，請務必設定快訊。
設定備用資源
如要增加讀取作業，請考慮新增唯讀備用資源。您可以使用 HAProxy、ProxySQL 或其他負載平衡器將讀取作業分散到多個唯讀備用資源中。
Cloud SQL 也支援鏈結複製功能，詳情請參閱串聯式備用資源的說明。
用於建立唯讀備用資源的 MySQL 版本與主要執行個體使用的相同。建立完成後，您可以選擇將備用資源升級為主要執行個體。
災難復原規劃
高可用性解決方案可以在相同區域的次要可用區中提供資料備援功能。災難發生時，某個區域可能無法使用。在災難復原計畫中，跨區域唯讀備用資源是強大的資源，可以視需要升級為主要執行個體。詳情請參閱說明文件。
相關產品和服務
Google Cloud 提供代管的 MySQL 資料庫，可滿足您的業務需求，包括淘汰地端部署資料中心、執行軟體式服務 (SaaS) 應用程式，以及遷移核心業務系統等。
