適用於 MySQL 的 Azure 資料庫 - 彈性伺服器的最佳效能最佳做法
瞭解如何在使用 適用於 MySQL 的 Azure 資料庫 彈性伺服器時獲得最佳效能。 當我們將新功能新增至平台時，我們將會繼續精簡本節中的建議。
實體鄰近性
請確定您在相同的區域中部署應用程式和資料庫。 啟動任何效能效能評定執行之前有一快速檢查方式，是使用簡單的 SELECT 1 查詢來判斷用戶端與資料庫之間的網路延遲。
當 Web 應用程式和其相關聯的資料庫等資源在不同的區域中執行時，這些資源之間的通訊可能會增加延遲。 讓應用程式和資料庫位於不同區域中會有另一個可能的影響，與輸出資料傳輸成本有關。
若要在成本優化部署中改善應用程式的效能和可靠性，強烈建議 Web 應用程式服務和 適用於 MySQL 的 Azure 資料庫 彈性伺服器資源位於相同的區域和可用性區域。 此共置最適合對延遲敏感的應用程式，而且也會提供最佳的輸送量，因為資源會緊密配對。
加速網路
如果您使用 Azure 虛擬機器、Azure Kubernetes 或應用程式服務，請使用應用程式伺服器的加速網路。 加速網路可以對 VM 啟用單一根目錄 I/O 虛擬化 (SR-IOV)，大幅提升其網路效能。 這個高效能路徑會略過資料路徑的主機，進而減少延遲、抖動和 CPU 使用率，供支援的 VM 類型中最嚴苛的網路工作負載使用。
連線效率
建立新的連線向來是昂貴且耗時的工作。 當應用程式要求資料庫連線時，會優先配置現有的閒置資料庫連線，而不是建立新的連線。 以下是適用於良好連線做法的一些選項：
ProxySQL：使用 ProxySQL，可提供內建連線共用，並視需要將工作負載負載平衡至多個讀取複本，並包含應用程式程式碼中的任何變更。
Heimdall Data Proxy：或者，您也可以使用 Heimdall Data Proxy，這是廠商中性的專屬 Proxy 解決方案。 該方案支援具有複寫延遲偵測的查詢快取和讀取/寫入分割。 您也可以參考如何使用 Heimdall Proxy 加速 MySQL 效能。
持續性或長時間存留連線：如果您的應用程式通常具有短交易或查詢，且執行時間 < 為 5-10 毫秒，則以持續性連線取代簡短連線。 將簡短連線取代為持續性連線只需要對程式碼進行次要變更，但在許多一般應用程式案例中改善效能方面會有重大影響。 請務必在交易完成時設定逾時或關閉連線。
複本：如果您使用複本，請使用 ProxySQL 來平衡主要伺服器與可讀取次要複本伺服器之間的負載。 了解如何設定對等互連。
連線共用
連線共用是一種機制，可管理資料庫連線的建立和配置，並保護資料庫免於連線激增。 如果您的應用程式在相對短時間內開啟許多連線，且連線存留時間較短，請考慮連線共用。 例如，這些連線類型的發生次數可能會超過每秒數百或數千，而且相較於連線存留期總計，建立和關閉連線所需的時間相當重要。
如果您的應用程式開發架構不支援連線共用，請改用應用程式與資料庫伺服器之間的連線 Proxy，例如 ProxySQL 或 Heimdall Proxy。
處理連線調整
調整 Web 應用程式以符合變動需求的常見方法，是新增和移除應用程式伺服器。 每個應用程式伺服器都可以搭配資料庫使用連接集區。 此方法會導致資料庫伺服器上的連線總數隨著應用程式伺服器數目而增長。 例如，如果資料庫伺服器有 10 部應用程式伺服器，且每個伺服器都設定為 100 個資料庫連線，則會提供 1000 個資料庫連線。 如果應用程式工作負載因使用者活動較高或尖峰時間而調整，且新增額外的 50 部應用程式伺服器，則資料庫連線總計為 6000。 一般而言，在應用程式伺服器建立連線之後，這些連線大部分都會閒置。 由於閑置聯機會耗用資源（記憶體和 CPU）保持開啟狀態，因此資料庫延展性可能會受到影響。
其他潛在挑戰涉及處理資料庫伺服器的連線總數。 這是由連線到資料庫伺服器的應用程式伺服器數目所決定，每個伺服器都會建立自己的一組連線。 在這些案例中，請考慮調整應用程式伺服器上的連線集區。 嘗試將每個集區中的連線數目減少為可接受的最小值，以確保資料庫伺服器端的連線沒有膨脹。 請將此視為短期補救措施，用於對抗應用程式伺服器調整的影響，而不是解決應用程式成長的永久解決方案。
作為長期解決方案，請在資料庫伺服器與應用程式伺服器之間引進 Proxy，例如 ProxySQL 或 Heimdall Proxy。 這會有所幫助，因為 Proxy 能夠：
- 建立具有固定連線數目的資料庫伺服器連線。
- 接受應用程式連線，並作為潛在連線風暴的緩衝區。
Proxy 可以提供其他功能，例如查詢快取、連線緩衝、查詢重寫/路由和負載平衡。 為了提升延展性，請考慮使用多個 Proxy 執行個體。
適合容錯和更快速復原的連線處理
設計應用程式和環境以進行容錯和更快速的復原時，請考慮在資料庫環境中，您可能會遇到連線中斷或硬體失敗的情況。 也請記住操作動作的需求，例如調整執行個體大小、修補和執行手動容錯移轉。
例如，假設您的資料庫伺服器在一分鐘內完成容錯移轉，但您的應用程式因為 DNS TTL 在應用程式端過長而關閉數分鐘。 在這些情況下，只要減少 TTL 值就能提供更快速的復原，或整合應用程式與資料庫伺服器之間的連線 Proxy 以便處理這類失敗。
資料分割
當您的生產工作負載使用非常大型的資料表時，資料分割是改善資料庫效能並簡化維護的絕佳方法。 資料分割可讓您更輕鬆地管理大型資料表，此方法可讓您新增和卸載分割區，以有效管理大型資料表。 資料分割也可以協助調整引擎，方法是降低每個資料表或每個索引的內部鎖定等內部結構競爭 (例如，考慮 InnoDB 中的 btr_search_latch in InnoDB)。
例如，藉由新增五個分割區，您基本上會將具有大量活動的資料表分成五個更有效率的較小資料表。 這主要有助於在數據表上主要作業是主鍵查閱的情況下，讓查詢可以利用「數據分割剪除」。 但是，資料分割也可以協助進行表格掃描。
雖然數據分割有其優點，但也有一些限制，例如在數據分割數據表中缺乏外鍵支持、查詢快取不足等。如需這些限制的完整清單，請參閱 MySQL 參考手冊中的<分割限制與限制>一章。
隔離讀取和寫入
大部分的應用程式主要都是從資料庫讀取，只有一小部分互動涉及寫入。 針對連接集區計算的主資料庫作用中連線數目，可能包含讀取流量。 盡可能卸載多個查詢來讀取複本，並節省對主要可寫入執行個體的存取權，這樣可增加應用程式伺服器執行的整體資料庫活動量，而不會增加主資料庫上的負載。 如果您尚未至少存取讀取複本以執行較長的查詢，例如報表，您應該考慮立即將報告或分析移至讀取複本。
讀取複本的更廣泛使用可能需要更仔細的考慮，因為複本因復寫的異步本質而稍微落後於主要複本。 盡可能尋找多個應用程式的區域，這些區域只需次要的程式碼變更，就能從複本讀取提供服務。 您也應該在有關快取的較高層級套用此方法 - 提供更多唯讀或緩慢變更來自專用快取層的內容，例如 Azure Cache for Redis。
寫入調整和分區化
隨著時間經過，應用程式會演進，以及新增功能。 為了方便或一般做法，資料表會新增至主資料庫。 若要處理資料庫上不斷成長的流量負載，請識別可輕鬆移至個別資料庫的應用程式區域，並考慮水平分區化或垂直分割資料庫。
水平分區化資料庫的運作方式，是在不同的資料庫中建立應用程式架構的多個複本，並根據客戶識別碼、地理位置或某些其他個別客戶或租用戶屬性來隔離客戶和所有相關聯的資料。 這適用於 SaaS 或 B2C 應用程式，其中個別客戶很小，且應用程式的負載來自數百萬個客戶的匯總使用量。 不過，B2B 應用程式比較困難，客戶的大小不同，而個別大型客戶可能會主宰特定分區的流量負載。
以功能分區化資料庫來垂直分割負載 - 將個別的應用程式網域 (或微服務) 移至自己的資料庫。 這會從主資料庫散發負載，以分隔個別服務資料庫。 簡單範例包括記錄資料表或月台組態資訊，這些資訊不需要與大量載入的訂單資料表位於相同資料庫中。 更複雜的範例包括將客戶和帳戶網域從訂單或履行網域中斷。 在某些情況下，這可能需要變更應用程式，例如修改電子郵件或背景工作佇列，以獨立運作，而不需要依賴聯結回到客戶或訂單數據表。 您可以使用 適用於 MySQL 的 Azure 資料庫 彈性伺服器讀取複本，將現有的數據表和數據移至新的主資料庫，並將應用程式的元件升級至新建立的可寫入資料庫， 新建立的資料庫必須限制連線集區的存取、微調查詢，以及使用自己的複本散佈負載，就像原始的主要複本一樣。
資料匯入組態
- 您可以在啟動資料匯入作業之前，暫時將執行個體調整為較高的 SKU 大小，然後在匯入成功時將其相應減少。
- 您可以使用移轉 MySQL 內部部署將數據匯入最少的停機時間，以 適用於 MySQL 的 Azure 資料庫 進行在線或離線移轉。
適用於 MySQL 的 Azure 資料庫 彈性伺服器記憶體建議
適用於 MySQL 的 Azure 資料庫 彈性伺服器效能最佳做法是配置足夠的 RAM，讓您的工作集幾乎完全位於記憶體中。
- 使用 適用於 MySQL 的 Azure 資料庫 彈性伺服器的計量，檢查是否使用記憶體百分比達到限制。
- 對此類數字設定警示，以確保當伺服器達到限制時，您可以採取提示動作來修正。 根據定義的限制，檢查資料庫 SKU 是否相應增加至較高的計算大小或較佳的定價層，這會導致大幅提升效能。
- 相應增加，直到您的效能數字在調整作業之後不再大幅下降。 如需監視資料庫實例計量的資訊，請參閱 適用於 MySQL 的 Azure 資料庫 彈性伺服器資料庫計量。
使用 InnoDB 緩衝集區準備
適用於 MySQL 的 Azure 資料庫 彈性伺服器實例重新啟動之後，系統會載入位於記憶體中的數據頁，因為查詢數據表會導致第一次執行查詢時延遲增加和效能變慢。 對於延遲敏感性工作負載而言，這可能無法接受。
使用 InnoDB 緩衝集區暖化，可藉由重載在重新啟動前緩衝集區中的磁碟頁面來存取對應的資料列，藉此得以縮短準備期間，而無須等待 DML 或 SELECT 作業。
您可以藉由設定 InnoDB 緩衝池伺服器參數，在重新啟動 適用於 MySQL 的 Azure 資料庫 彈性伺服器實例之後，減少熱身期間。 InnoDB 會在伺服器關機時儲存每個緩衝集區最近使用的頁面百分比，並在伺服器啟動時還原這些頁面。
也請務必注意，改善的效能需要花費伺服器較長的啟動時間。 啟用此參數時，伺服器啟動和重新啟動時間應該會根據伺服器上佈建的 IOPS 而增加。
建議您測試並監視重新啟動時間，以確保啟動/重新啟動效能可以接受，因為伺服器在該時間無法使用。 不建議在佈建的 IOPS 少於 1000 (或換句話說，佈建的儲存體小於 335 GB) 時使用此參數。
若要在伺服器關機時儲存緩衝集區的狀態，請將伺服器參數 innodb_buffer_pool_dump_at_shutdown 設定為 ON。 同樣地，請將伺服器參數 innodb_buffer_pool_load_at_startup 設定為 ON，以在伺服器啟動時還原緩衝集區狀態。 您可以降低和微調伺服器參數 innodb_buffer_pool_dump_pct 的值，來控制對啟動/重新啟動時間的影響。 根據預設，此參數設定為 25。
注意
InnoDB 緩衝集區準備參數僅在最多 16 TB 儲存體的一般用途儲存體伺服器中受支援。 如需詳細資訊，請參閱 適用於 MySQL 的 Azure 資料庫 彈性伺服器記憶體選項。