將 MySQL 內部部署移轉至適用於 MySQL 的 Azure 資料庫：最佳化
適用於：
適用於 MySQL 的 Azure 資料庫 - 單一伺服器適用於 MySQL 的 Azure 資料庫 - 彈性伺服器
必要條件
監視硬體和查詢效能
除了稽核及活動記錄之外，也可以使用 Azure 計量來監視伺服器效能。Azure 計量會以一分鐘的頻率提供，而且可以從中設定警示。 如需詳細資訊，請參閱在適用於 MySQL 的 Azure 資料庫中進行監視，以取得可監視計量類型的詳細資訊。
如先前所述，在決定升級資料庫層時，監視計量 (例如 cpu_percent 或 memory_percent) 可能很重要。 一致的高值可能表示需要階層升級。
此外，如果 CPU 和記憶體似乎不是問題，則系統管理員可以探索資料庫型選項 (例如索引編制和查詢修改)，以了解效能不佳的查詢。
若要尋找效能不佳的查詢，請執行下列命令：
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlSlowLogs'
| project TimeGenerated, LogicalServerName\_s,
event\_class\_s, start\_time\_t , q uery\_time\_d,
sql\_text\_s| top 5 by query\_time\_d desc
查詢效能深入解析
除了基本伺服器監視層面之外，Azure 還提供工具來監視應用程式查詢效能。 更正或改善查詢可能會導致查詢輸送量大幅增加。 使用查詢效能深入解析工具來分析長時間執行的查詢，並判斷是否可以在設定期間內快取這些項目，或修改查詢以提升其效能。
slow\_query\_log 可以設定為在 MySQL 記錄檔中顯示緩慢查詢 (預設值為 OFF)。 long\_query\_time 伺服器參數可以警示使用者長時間查詢時間 (預設值為 10 秒)。
升級階層
Azure 入口網站可用來在 General Purpose 與 Memory Optimized 之間調整。 如果選擇 Basic 階層，則稍後沒有任何選項可將階層升級至 General Purpose 或 Memory Optimized。 不過，您可以利用其他技術來執行移轉/升級至新的適用於 MySQL 的 Azure 資料庫執行個體。
如需從基本層遷移至另一個伺服器層的指令碼範例，請參閱從基本層升級至一般用途或適用於 MySQL 的 Azure 資料庫中的記憶體最佳化層。
調整伺服器
在階層中，您可以將核心及記憶體調整為該層中允許的最小和最大限制。 如果監視顯示持續達到 CPU 或記憶體上限，請遵循步驟相應增加以符合您的需求。
移動區域
將資料庫移至不同的 Azure 區域取決於方法和結構。 視方法而定，這可能會導致系統停機。
建議的程序與使用讀取複本進行維護容錯移轉相同。 不過，相較於上述計劃性維護方法，在應用程式中實作容錯移轉層時，容錯移轉的速度會更快。 在讀取複本容錯移轉程序期間，應用程式應該只會短暫關閉。 「商務持續性和災害復原」一節中涵蓋更多詳細資料。
WWI 案例
WWI 企業和應用程式使用者對於能夠調整隨需資料庫表示高度期待。 他們也有興趣使用查詢效能深入解析來判斷是否需要處理長時間執行的查詢效能。
他們選擇針對任何潛在的容錯移轉或唯讀必要案例使用讀取複本伺服器。
移轉小組會與 Azure 工程師合作設定 KQL 查詢，以監視 MySQL 伺服器效能的任何潛在問題。 KQY 查詢已設定警示，以電子郵件將事件問題傳送給資料庫和會議小組。
他們選擇立即監視任何潛在問題，並視需要稍後實作 Azure 自動化 Runbook，以改善作業效率。
最佳化檢查清單
監視緩慢的查詢。
定期檢閱效能深入解析儀表板。
利用監視來推動階層升級和調整決策。
請考慮移動使用者的區域或需要變更的應用程式。