將 MySQL 內部部署移轉至適用於 MySQL 的 Azure 資料庫：效能基準
建立效能基準對於將 MySQL 資料庫從內部部署環境遷移至 適用於 MySQL 的 Azure 資料庫 至關重要。 本文探討效能基準的重要性，並提供測量和分析您目前資料庫效能的詳細指南。 藉由瞭解您現有的效能計量，您可以設定實際的期望，並識別移轉程式期間改善的領域。 本指南可讓您瞭解建立精確的效能基準，以確保移轉的資料庫符合或超過其在 Azure 環境中的目前效能等級。 無論您的目標是優化查詢效能、增強延展性或確保一致的用戶體驗，本文都提供達成效能目標所需的深入解析。
必要條件
將 MySQL 內部部署移轉至 適用於 MySQL 的 Azure 資料庫：測試計劃
概觀
了解現有的 MySQL 工作負載是可進行的最佳投資之一，以確保成功移轉。 絕佳的系統效能取決於足夠的硬體和絕佳的應用程式設計。 CPU、記憶體、磁碟和網路等項目必須針對預期的負載適當重設大小和設定。 硬體和設定是系統效能方程式的一部分。 開發人員必須了解資料庫查詢載入和執行成本最高的查詢。 專注於最昂貴的查詢可能會大幅影響整體效能計量。
建立查詢效能基準對移轉項目至關重要。 效能基準可用來驗證已移轉資料工作負載的 Azure 登陸區域設定。 大部分的系統都是以 24/7 執行，且負載時間不同。 請務必擷取基準的尖峰工作負載。 計量會擷取數次。 稍後在文件中，我們會探索來源伺服器參數，以及這些參數對於整體效能基準有何重要性。 移轉項目期間不應忽略伺服器參數。
工具
以下是用來收集伺服器計量和資料庫工作負載資訊的工具。 使用擷取的計量來判斷適用於 MySQL 層的適當 Azure 資料庫和相關聯的調整選項。
MySQL 企業監視器： 此非免費企業版工具可以提供最昂貴查詢、伺服器計量、檔案 I/O 和拓撲資訊的排序列表
Percona Monitoring and Management (PMM)：最佳開放原始碼資料庫監視解決方案。 無論部署的位置為何，其有助於降低複雜度、最佳化效能，以及改善商務關鍵性資料庫環境的安全性。
伺服器參數
MySQL 伺服器預設組態可能無法充分支援工作負載。 MySQL 中有大量的伺服器參數，但在大多數情況下，移轉小組應該將焦點放在少數幾個。 在來源和目標環境中應該評估下列參數。 不正確的設定會影響移轉的速度。 當我們執行移轉步驟時，我們會再次重新流覽這些參數。
innodb_buffer_pool_size：大型值可確保先使用記憶體內部資源，再使用磁碟 I/O。 一般值的範圍從 80% 到 90% 的可用記憶體。 例如，具有 8 GB 記憶體的系統應該為集區大小配置 5-6 GB。
innodb_log_file_size：重做記錄可確保快速且持久的寫入。 此交易式備份在系統當機期間很有幫助。 從innodb_log_file_size開始 = 512M （提供 1 GB 的重做記錄）應該提供大量的寫入空間。 使用 MySQL 5.6 或更高版本的大量寫入應用程式應該從 innodb_log_file_size = 4G 開始。
max_connections：此參數可以協助減輕
Too many connections錯誤。 預設值是 151 個連線。 最好在應用層級使用聯機集區，但伺服器聯機組態可能也需要增加。innodb_file_per_table：此設定會告知 InnoDB 是否應該將數據和索引儲存在共用數據表空間或每個數據表的個別.ibd 檔案中。 每個資料表都有檔案可讓伺服器在捨棄、截斷或重建資料表時回收空間。 包含許多數據表的資料庫不應該使用每個檔案組態的數據表。 從 MySQL 5.6 起，預設值為「開啟」。 舊版資料庫應該在載入資料之前，設定為「開啟」。 此設定只會影響新建立的資料表。
innodb_flush_log_at_trx_commit：其中一個的預設設定表示 InnoDB 完全符合 ACID 規範。 這種風險較低的交易組態可能會對磁碟速度緩慢的系統造成重大額外負荷，因為需要額外的同步處理，才能排清重做記錄的每個變更。 將參數設定為 2 比較不可靠，因為認可的交易只會一秒一次排清到重做記錄。 在某些主要情況下，風險是可以接受的，而且對於複本來說是個好值。 值為 0 可提升系統效能，但資料庫伺服器在失敗期間可能會遺失某些數據。 底線是只針對復本使用0值。
innodb_flush_method：此設定會控制資料和記錄排清到磁碟的方式。 當
O_DIRECT硬體RAID控制器具有受電池保護的回寫快取時使用。 針對其他案例使用fdatasync(預設值)。innodb_log_buffer_size：此設定是尚未認可之交易的緩衝區大小。 預設值 （1 MB） 是可接受的。 具有大型 Blob/文字字段的交易可以快速填滿緩衝區，並觸發額外的 I/O 負載。 檢視
Innodb_log_waits狀態變數，如果不是 0，請增加innodb_log_buffer_size。query_cache_size：查詢快取是已知瓶頸，可在仲裁並行其間看見。 初始值應該設定為 0 以停用快取，例如，query_cache_size = 0。 這是 MySQL 5.6 和更新版本上的預設值。
log_bin：此設定會啟用二進位記錄。 如果伺服器是作為複寫主機，則啟用二進位記錄是必要的。
server_id：此設定對複製拓撲中的識別伺服器而言是唯一的。
expire_logs_days：此設定可控制將自動清除二進位記錄的天數。
skip_name_resolve：使用者執行用戶端主機名稱解析。 如果 DNS 緩慢，則連線速度很慢。 停用名稱解析時，GRANT 陳述式只能使用 IP 位址。 任何先前的 GRANT 語句都必須重做才能使用 IP。
執行下列命令，將伺服器參數匯出至檔案以供檢閱。 使用一些簡單的剖析，在移轉之後，輸出可以重新套用相同的伺服器參數，如果適當的話，就會套用到 適用於 MySQL 的 Azure 資料庫 伺服器。 請參考使用 Azure 入口網站在適用於 MySQL 的 Azure 資料庫中設定伺服器參數。
mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt
您可以在附錄中找到 MySQL 5.5.60 預設安裝的伺服器參數。
移轉開始之前，請匯出來源 MySQL 組態設定。 在移轉之後，將這些值與 Azure 登陸區域執行個體設定進行比較。 如果已從目標 Azure 登陸區域實例中的預設值修改任何設定，請確定移轉後會設定這些設定。 此外，移轉使用者應該在移轉之前先確認可以設定伺服器參數。
如需無法設定的伺服器參數清單，請參考 不可設定的伺服器參數。
輸出和輸入
來源和目標 MySQL 伺服器參數必須針對每個個別的數據遷移工具和路徑進行修改，以支援最快的輸出和輸入。 視工具而定，參數可能不同。 例如，平行執行移轉的工具可能需要來源與目標與單個線程工具之間的更多連線。
檢閱可能受數據集影響的任何逾時參數。 其中包括：
此外，請檢閱影響最大值的任何參數：
注意
常見的移轉錯誤是 MySQL server has gone away。 這裡所述的參數是解決此錯誤的典型原因。
WWI 案例
WWI 已檢閱其會議資料庫工作負載，並判斷其負載很小。 雖然基本層伺服器適用於它們，但稍後他們不想執行工作以移轉至另一層。 部署的伺服器最終會裝載其他 MySQL 數據工作負載，因此他們挑選了該 General Performance 層。
檢閱 MySQL 資料庫時，我發現 MySQL 5.5 伺服器會在初始安裝期間使用設定的預設伺服器參數執行。