在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器上進行伺服器作業的最佳做法
了解使用適用於 MySQL 的 Azure 資料庫彈性伺服器的最佳做法。 我們將隨著平台新增功能，持續專注於改進本節中詳述的最佳做法。
適用於 MySQL 的 Azure 資料庫彈性伺服器操作指導方針
以下是使用適用於 MySQL 的 Azure 資料庫彈性伺服器時，為了改善資料庫效能所應遵循的操作指導方針：
共置：若要縮短網路延遲，請將用戶端和資料庫伺服器放在相同的 Azure 區域中。
監視您的記憶體、CPU 和儲存體使用量：您可以設定警示，在使用量模式有所變更或接近部署容量時獲取通知，以便維護系統效能和可用性。
增強效能的加速記錄：啟用加速記錄功能可最佳化交易式記錄相關作業，提升伺服器輸送量和效能。 這項功能不需額外費用，是業務關鍵服務層級的使用者最佳操作做法的重要補充。
擴大 DB 執行個體：在即將達到儲存體容量限制時，可進行擴大。 您的儲存體和記憶體應設有緩衝，以因應應用程式需求非預期的增加。 您也可以啟用儲存體自動成長功能，以確保服務在接近儲存體限制時會自動調整儲存體。
設定備份：根據商務需求啟用本機或異地備援備份。 此外，您可以根據備份可用於商務持續性的時間長度，來修改保留期間。
使用自動調整 IOPS 最佳化 I/O 容量：如果資料庫工作負載所需的 I/O 比佈建的還要多，則資料庫的復原或其他交易作業將會變慢。 若要增加伺服器執行個體的 I/O 容量，請執行下列任一動作：
調整計算：資料庫工作負載也可能因為 CPU 或記憶體而受到限制，這可能會對交易處理造成嚴重影響。 計算（定價層）只能在一般用途或記憶體優化層之間相應增加或減少。
測試容錯移轉：為您的伺服器執行個體手動測試容錯移轉，以了解您的使用案例完成程序需要多少時間，並確定存取伺服器執行個體的應用程式在容錯移轉之後可自動連線至新的伺服器執行個體。
使用主索引鍵：當您在適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體上操作時，請確定您的資料表具有主索引鍵或唯一索引鍵。 這對於進行備份、複本等作業很有幫助，並且能提升效能。
設定 TTL 值：如果您的用戶端應用程式會快取伺服器執行個體的網域名稱服務 (DNS) 資料，請設定小於 30 秒的存留時間 (TTL) 值。 由於伺服器執行個體的基礎 IP 位址在容錯移轉之後可能會變更，因此，如果您的應用程式嘗試連線至不再提供服務的 IP 位址，長時間快取 DNS 資料可能會導致連線失敗。
使用連線共用以避免達到最大連線限制，並使用重試邏輯來避免間歇性連線問題。
如果您使用複本，請使用 ProxySQL 來平衡主要伺服器與可讀取次要複本伺服器之間的負載。 請參閱這裡的設定步驟。
佈建資源時，請確定您已為適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體啟用自動成長。 這不會增加任何額外的成本，並且可保護資料庫免於遭受任何可能的儲存體瓶頸影響。
搭配 適用於 MySQL 的 Azure 資料庫 彈性伺服器使用 InnoDB
如果使用
ibdata1功能 (這是系統資料表空間)，則無法藉由從資料表中卸除資料或將資料表移至 file-per-tabletablespaces，來壓縮或清除資料檔案。對於大小超過 1 TB 的資料庫，您應在 innodb_file_per_table
tablespace中建立資料表。 對於大小超過 1 TB 的單一資料表，您應使用分割區資料表。對於具有大量
tablespace的伺服器，引擎啟動會因為適用於 MySQL 的 Azure 資料庫彈性伺服器啟動或容錯移轉期間的循序資料表空間掃描而非常緩慢。如果資料表總數小於 500，請在建立資料表之前設定 innodb_file_per_table = ON。
如果您在資料庫中有超過 500 個資料表，請檢閱每個資料表的資料表大小。 對於大型資料表，您仍應考慮使用 file-per-table 資料表空間，以避免系統資料表空間檔案達到最大儲存體限制。
注意
對於大小不到 5GB 的資料表，請考慮使用系統資料表空間
CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;
如果您有較大的資料表可能會成長到 1 TB 以上，請在建立資料表時分割資料表。
使用多個適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體，並將資料表分散到這些伺服器。 如果您有大約 10,000 個或更多資料表，請避免將太多資料表放在單一伺服器上。