共用方式為

使用 sys_schema 在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中微調效能並維護資料庫

  • 發行項

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

重要

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

最先在 MySQL 5.5 中導入的 MySQL performance_schema，能針對許多重要伺服器資源 (例如記憶體配置、預存程式、中繼資料鎖定等) 提供檢測功能。不過，performance_schema 包含超過 80 個資料表，且通常需要聯結 performance_schema 內的資料表以及 information_schema 中的資料表，才能取得所需的資訊。 sys_schema以performance_schema和information_schema為基礎，在唯讀資料庫中提供功能強大的用戶易記檢視集合，並在 適用於 MySQL 的 Azure 資料庫 彈性伺服器 5.7 版中完全啟用。

sys_schema 的檢視。

sys_schema 中有 52 個檢視，每個檢視分別具有下列其中一個前置詞：

  • Host_summary 或 IO：I/O 相關的延遲。
  • InnoDB：InnoDB 緩衝區狀態和鎖定。
  • Memory：依主機和使用者分類的記憶體使用量。
  • Schema：結構描述相關的資訊，例如自動增量、索引等等。
  • Statement：SQL 陳述式相關的資訊；這可以是導致完整資料表掃描或長時間查詢的陳述式。
  • User：使用者所耗用並依使用者分類的資源。 範例包括檔案 I/O、連線和記憶體。
  • Wait：依主機或使用者分類的等候事件。

現在，讓我們看看 sys_schema 的一些常見使用模式。 首先，我們會將使用模式分成兩個類別：效能微調和資料庫維護。

效能微調

sys.user_summary_by_file_io

IO 是資料庫中成本最高的作業。 我們可以藉由查詢 sys.user_summary_by_file_io 檢視來找出平均 IO 延遲。 使用 125 GB 的預設佈建儲存體時，我的 IO 延遲大約是 15 秒。

IO 延遲：125 GB。

因為 適用於 MySQL 的 Azure 資料庫 彈性伺服器會隨著記憶體調整 IO，因此在將布建的記憶體增加到 1 TB 之後，我的 IO 延遲會減少到 571 毫秒。

IO 延遲：1TB。

sys.schema_tables_with_full_table_scans

儘管經過仔細規劃，許多查詢仍可能導致完整資料表掃描。 如需索引類型以及如何將索引最佳化的詳細資訊，請參閱這篇文章：如何對查詢效能進行疑難排解。 完整資料表掃描會耗用大量資源，並降低資料庫效能。 透過完整資料表掃描來尋找資料表的最快方式是查詢 sys.schema_tables_with_full_table_scans 檢視。

完整資料表掃描。

sys.user_summary_by_statement_type

對資料庫效能問題進行疑難排解時，識別您的資料庫內發生的事件可能會有幫助，而使用 sys.user_summary_by_statement_type 檢視可能可以協助做到這一點。

依陳述式分類的摘要。

在此範例中，適用於 MySQL 的 Azure 資料庫 彈性伺服器花了 53 分鐘的時間排清慢速查詢記錄 44579 次。 這不僅耗時，也需要許多 IO。 您可以停用慢速查詢記錄，或減少慢速查詢登入至 Azure 入口網站的頻率，來減少這項活動。

資料庫維護

sys.innodb_buffer_stats_by_table

[!IMPORTANT]

查詢此檢視表可能會影響效能。 建議在離峰上班時間執行此疑難排解。

InnoDB 緩衝集區存在於記憶體中，是 DBMS 與儲存體之間的主要快取機制。 InnoDB 緩衝集區的大小會繫結至效能層，除非選擇不同的產品 SKU，否則無法變更。 如同作業系統中的記憶體，系統會移出舊的頁面以騰出空間給最新的資料。 若要了解哪些資料表耗用了大部分的 InnoDB 緩衝集區記憶體，您可以查詢 sys.innodb_buffer_stats_by_table 檢視。

InnoDB 緩衝區狀態。

從上圖可以明顯看出，除了系統資料表和檢視以外，mysqldatabase033 資料庫 (其裝載其中一個「我的 WordPress」網站) 中的每個資料表都在記憶體中佔用 16 KB (或 1 頁) 的資料。

Sys.schema_unused_indexes 與 sys.schema_redundant_indexes

索引是提升讀取效能的理想工具，但它們會造成插入和儲存方面的額外成本。 Sys.schema_unused_indexes 和 sys.schema_redundant_indexes 可為您提供未使用或重複索引的見解。

未使用的索引。

重複的索引。

結論

總而言之，sys_schema 對效能調整和資料庫維護而言，都是很理想的工具。 請務必在 適用於 MySQL 的 Azure 資料庫 彈性伺服器實例中利用這項功能。

下一步

  • 若想知道是否有人可解答您最關切的問題，或是要張貼新問題/解答，請造訪堆疊溢位。