從 Aurora 遷移至 MySQL 適用的 Cloud SQL 之前，需要考量的重要事項

Aurora 使用預設的字元集伺服器 latin1 (直到 MySQL v5.7 為止)。這與 MySQL 適用的 Cloud SQL 資料庫、資料表、儲存的程序和函式的預設設定不同。在遷移期間，這些預設設定是以 utf8 做為預設字元集來建立。這可能會導致效能出現問題。

舉例來說，使用者可能最終會陷入一種狀況，就是資料表是以 latin1 字元集建立，而預存程序或函式則是以 Cloud SQL 預設的 utf8 字元集建立。在這類情況下，如果儲存的程序或函式預期變數為 utf8 參數，並將該變數與資料欄值 (使用 latin1 字元集) 進行比較，就會因兩種不同字元集的比較和定序造成效能問題。

您可以使用下列指令，檢查處理常式的字元集：

mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES;

如果您使用 Aurora 中的預設字元集 (直到 v5.7 為止)，也就是使用 latin1，則在匯入資料之前，應將 Cloud SQL 中的預設字元集從 utf8 變更為 latin1。

另一個解決方案是將所有內容變更為 utf8，但在這種情況下，使用者應測試完整的應用程式和資料集，因為變更字元集可能會導致資料無法如預期呈現。

使用者可以透過以下方式，在旗標區段下方編輯 Cloud SQL 執行個體的這項設定。

Aurora MySQL 5.7 有大量定序 (例如字元集 utf8mb4 適用的 utf8mb4_0900_ai_ci)，目前僅適用於 MySQL 適用的 Cloud SQL 8.0。如果您使用任何這類定序，並且匯入 MySQL 適用的 Cloud SQL 5.7 中的資料，系統會顯示以下錯誤訊息「Error 'Character set '#255' is not a compiled character set」(錯誤字元集 '#255' 不是經過編譯的字元集)。

解決方法是在 MySQL 5.7 版中，將這些定序變更為可用的定序。

與 Aurora 不同，MySQL 適用的 Cloud SQL 不支援 MyISAM 引擎。從 Aurora 遷移至 Cloud SQL 之前，建議先將所有資料表轉換至 InnoDB。

如果 InnoDB 之外的引擎中有資料表，使用者可以使用「ALTER」指令變更資料表的引擎：

mysql> alter table table_1 engine='Innodb' ;

Query OK, 0 rows affected (2.89 sec)

Records: 0 Duplicates: 0 Warnings: 0

注意：查詢時間視資料表大小而定，且系統可能會鎖定同一個資料表上的其他作業。您也可以使用線上結構定義變更工具，例如 pt-online-schema-change 或 gh-ost，在不封鎖其他作業的情況下修改資料表。

在 Aurora 中，使用者可以在單一端點後方設定多個讀取器，但 MySQL 適用的 Cloud SQL 使用者沒有這項立即可用的功能。MySQL 適用的 Cloud SQL 中的每個唯讀備用資源都有自己的 IP，而使用者必須使用如 ProxySQL 等，將流量分配至多個唯讀備用資源執行個體。

以下指南說明如何使用 ProxySQL 在多個唯讀備用資源之間轉送流量。

變更緩衝區是一種特殊的資料結構，可以在次要索引頁面不在緩衝區集區中時，快取這些頁面變更，並於稍後其他讀取作業載入這些頁面至緩衝區集區時，加以合併。詳情請參閱變更緩衝區。

以工作負載在含有次要索引的資料表上執行大量寫入作業而言，Aurora 的執行速度可能比 MySQL 適用的 Cloud SQL 慢，後者會使用預設的 InnoDB 變更緩衝區功能，將更新延後至稍晚的工作階段。使用者應根據應用程式工作負載來衡量效能。

查詢快取會將選取指令及其結果儲存在中繼儲存空間層中。如果之後收到相同的陳述式，伺服器會從查詢快取擷取結果並檢查，而非再次執行該指令。系統會在多個工作階段之間共用查詢快取，因此所有工作階段都能從其他工作階段已執行的陳述式所快取的結果中受益。進一步瞭解查詢快取。

Aurora 預設會啟用查詢快取，不過 MySQL Community 已停用 5.7 版中的查詢快取，並在 8.0 版本中完全移除該快取，MySQL 適用的 Cloud SQL 也是如此。如果您的查詢依賴 Aurora 的查詢快取功能，在 MySQL 適用的 Cloud SQL 中的效能可能會有所不同。建議您比較使用 Aurora 的執行時間，藉此測試在 MySQL 適用的 Cloud SQL 中的查詢效能。

針對一個區域內的唯讀備用資源，Aurora 採用的叢集磁碟區概念，會在該區域的三個可用區中複製資料。Aurora 的複製延遲時間通常不會超過 100 毫秒，因為相同資料庫叢集內的主要資源與備用資源都會將叢集磁碟區中的資料視為單一邏輯磁碟區。此外，對於跨區域的唯讀備用資源，Aurora 採用基於磁碟的跨區域資料同步作業，而非基於二進位記錄檔的複製功能。

簡單來說，複製作業會由 Aurora 的儲存空間層處理，而在 MySQL 適用的 Cloud SQL 中，標準複製機制會將二進位記錄檔轉移至備用資源執行個體，並在使用 MySQL 執行個體的備用資源中重播這些記錄檔。我們可以在 Cloud SQL 中設定平行複製功能，以改善複製效能。請參閱設定平行複製功能的詳細資料。

雖然複製延遲取決於應用程式以及主要執行個體和備用資源執行個體之間的網路的變更資料量，但大多數應用程式都可以正常運作，而且在 Aurora 和 MySQL 適用的 Cloud SQL 中都不會有明顯的延遲。不過，如果應用程式需要大量寫入，且應用程式正在讀取備用資源，那麼建議您先在 AWS Aurora 和 MySQL 適用的 Cloud SQL 中對複製延遲進行基準測試，再進行遷移。

MySQL 適用的 Cloud SQL 採用 GTID 複製功能，與 AWS Aurora 的磁碟型資料同步處理機制不同。如果應用程式工作流程有倚賴任一個這類功能，使用者應在遷移前檢查下列 GTID 的限制，並在應用程式中執行所有必要的變更：

• 使用 GTID 型的複製功能時，不允許使用 CREATE TABLE ... SELECT 陳述式。
• 交易、程序、函式和觸發條件中不支援 CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 陳述式。您可以在 GTID 啟用時使用這些陳述式，但只能在任何交易以外使用，而且只能使用 autocommit=1。

如要進一步瞭解以 GTID 為基礎的限制，請參閱 GTID 的限制。