Share via

使用適用於 MySQL 的 Azure 資料庫建立應用程式的最佳作法

  • 發行項

適用於：適用於 MySQL 的 Azure 資料庫 - 單一伺服器適用於 MySQL 的 Azure 資料庫 - 彈性伺服器

重要

適用於 MySQL 的 Azure 資料庫單一伺服器位於淘汰路徑上。 強烈建議您升級至適用於 MySQL 的 Azure 資料庫彈性伺服器。 如需移轉至適用於 MySQL 的 Azure 資料庫彈性伺服器的詳細資訊，請參閱適用於 MySQL 的 Azure 資料庫單一伺服器會發生什麼事？

以下一些最佳做法可協助您使用適用於 MySQL 的 Azure 資料庫來建置雲端就緒的應用程式。 這些最佳做法可減少應用程式的開發時間。

應用程式和資料庫資源的設定

將應用程式和資料庫保留在相同的區域中

在 Azure 中部署應用程式時，請確定您的所有相依性都位於相同區域中。 將執行個體分散在不同區域或可用性區域會造成網路延遲，可能會影響應用程式的整體效能。

保護您的 MySQL 伺服器安全

將您的 MySQL 伺服器設定為安全，而且無法公開存取。 使用下列其中一個選項來保護您的伺服器：

基於安全性，您必須一律透過 SSL 連線至 MySQL 伺服器，並將 MySQL 伺服器和應用程式設定為使用 TLS 1.2。 請參閱如何設定 SSL/TLS。

搭配使用進階網路與 AKS

在 VM 上啟用加速網路時，可降低延遲、抖動和 VM 上的 CPU 使用率。 若要深入了解，請參閱Azure Kubernetes Service 和適用於 MySQL 的 Azure 資料庫的最佳做法。

微調伺服器參數

針對大量讀取工作負載微調伺服器參數，tmp_table_size 和 max_heap_table_size 可協助最佳化以提升效能。 若要計算這些變數所需的值，請查看每一連線和基底記憶體的總值。 個別連線記憶體參數的總和，不包括 tmp_table_size，與基底記憶體帳戶合併為伺服器總記憶體。

若要計算 tmp_table_size 與 max_heap_table_size 的最大可能大小，請使用下列公式：

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

注意

記憶體總計指出伺服器跨已佈建虛擬核心的記憶體數量總計。 例如，在一般用途二虛擬核心適用於 MySQL 的 Azure 資料庫伺服器中，記憶體總計將會是 5 GB * 2。 您可以在定價層文件中找到每層記憶體的詳細資料。

基底記憶體指出 MySQL 將在伺服器啟動時初始化和配置的記憶體變數 (例如 query_cache_size 和 innodb_buffer_pool_size)。 每個連線記憶體 (例如 sort_buffer_size 和 join_buffer_size) 是只在查詢需要時才配置的記憶體。

建立非管理使用者

為每個資料庫建立非管理使用者。 一般而言，使用者名稱會識別為資料庫名稱。

重設密碼

您可以使用 Azure 入口網站為 MySQL 伺服器重設密碼。

重設生產資料庫的伺服器密碼可能會關閉您的應用程式。 最好在離峰時段重設任何生產工作負載的密碼，以將對您應用程式使用者的影響降到最低。

效能和復原

以下是一些可協助偵錯應用程式效能問題的工具和做法。

啟用慢速查詢記錄以識別效能問題

您可以在伺服器上啟用慢速查詢記錄和稽核記錄。 分析慢速查詢記錄可協助識別效能瓶頸，以進行疑難排解。

透過 Azure 監視器記錄、Azure 事件中樞和儲存體帳戶中的 Azure 診斷記錄也可以取得稽核記錄。 請參閱如何對查詢效能問題進行疑難排解。

使用連接共用

管理資料庫連線，可能會對應用程式整體的效能產生重大影響。 若要最佳化效能，您必須減少連線建立次數，以及在金鑰程式碼路徑中建立連線的時間。 使用連線共用來連線至適用於 MySQL 的 Azure 資料庫，以改善復原和效能。

您可以使用 ProxySQL 連線共用器有效率地管理連線。 使用連線共用器可能會減少閒置連線，並重複使用現有連線，而這有助於避免問題。 若要深入了解，請參閱如何設定 ProxySQL。

重試邏輯以處理暫時性錯誤

您的應用程式可能會遇到暫時性錯誤，其中資料庫連線會中斷或間歇性遺失。 在這種情況下，伺服器會在 5 到 10 秒內重試一到兩次之後啟動並執行。

最佳做法是在第一次重試之前等候 5 秒。 然後在每次重試之後，逐漸增加等候時間，最多 60 秒。 限制應用程式將作業考慮為失敗的重試次數上限，以讓您進一步調查。 若要深入了解，請參閱如何針對連線錯誤進行疑難排解。

啟用讀取複寫以減輕容錯移轉

在容錯移轉案例中，您可以使用資料輸入複寫。 使用讀取複本時，來源與複本伺服器之間不會進行自動容錯移轉。

您會注意到來源與複本之間的延遲，因為複寫屬於非同步。 網路延遲可能會受到許多因素影響，例如在來源伺服器上執行的工作負載數量，以及資料中心之間的延遲。 在多數情況下，複本延遲會是幾秒鐘到幾分鐘。

資料庫部署

在 CI/CD 部署管線中設定適用於 MySQL 的 Azure 資料庫工作

有時候，您必須將變更部署至資料庫。 在這類情況下，您可以透過 Azure Pipelines 使用持續整合 (CI) 和持續傳遞 (CD)，並使用 MySQL 伺服器的工作，以對資料庫執行自訂指令碼來進行更新。

使用有效的程序進行手動資料庫部署

在手動資料庫部署期間，請遵循下列步驟以將停機時間降到最低，或降低部署失敗的風險：

  1. 使用 mysqldump 或 MySQL Workbench，在新的資料庫上建立生產資料庫複本。
  2. 使用資料庫所需的新結構描述變更或更新來更新新的資料庫。
  3. 將生產資料庫置於唯讀狀態。 在部署完成前，最好不要在生產資料庫上進行寫入作業。
  4. 使用步驟 1 中新更新的資料庫測試您的應用程式。
  5. 部署應用程式變更，並確定應用程式現在使用具有最新更新的新資料庫。
  6. 保留舊的生產資料庫，以復原變更。 然後，您可以評估是否刪除舊的生產資料庫，或視需要將其匯出至 Azure 儲存體。

注意

如果應用程式類似電子商務應用程式，而且您無法將其置於唯讀狀態，則請在進行備份之後直接在生產資料庫上部署變更。 這些變更應該在離峰時段且應用程式低流量的時間執行，以將影響降到最低，因為某些使用者可能會遇到失敗的要求。

請確定您的應用程式碼也會處理任何失敗的要求。

使用 MySQL 原生計量來查看您的工作負載是否超過記憶體內部暫存資料表大小

使用大量讀取工作負載時，針對 MySQL 伺服器的查詢可能會超過記憶體內部暫存資料表大小。 大量讀取工作負載可能會導致您的伺服器切換至將暫存資料表寫入至磁碟，而影響應用程式的效能。 若要判斷伺服器是否因超過暫存資料表大小而寫入至磁碟，請查看下列計量：

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

created_tmp_disk_tables 計量指出磁碟上已建立的資料表數目。 如果有您的工作負載，則 created_tmp_table 計量會告訴您必須在記憶體中形成多少暫存資料表。 若要判斷特定查詢是否會使用暫存資料表，請在查詢上執行 EXPLAIN 陳述式。 如果查詢將使用暫存資料表執行，則 extra 資料行中的詳細資料會指出 Using temporary。

若要計算工作負載的百分比，而且查詢溢出到磁碟，請使用下列公式中的計量值：

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

在理想情況下，此百分比應該小於 25%。 如果百分比為 25% 或更大，則建議您修改兩個伺服器參數：tmp_table_size 和 max_heap_table_size。

資料庫結構描述和查詢

以下是建置資料庫結構描述和查詢時要記住的一些秘訣。

針對資料表資料行使用正確的資料類型

根據您想要儲存的資料類型使用正確的資料類型，可以將儲存體最佳化，並減少因資料類型不正確而發生的錯誤。

使用索引

若要避免慢速查詢，您可以使用索引。 索引可協助快速尋找具有特定資料行的資料列。 請參閱如何在 MySQL 中使用索引。

針對您的 SELECT 查詢使用 EXPLAIN

使用 EXPLAIN 陳述式來深入解析 MySQL 所執行以執行查詢的動作。 其可協助您偵測查詢的瓶頸或問題。 請參閱如何使用 EXPLAIN 剖析查詢效能。