使用 sys_schema 在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中微調效能並維護資料庫
最先在 MySQL 5.5 中導入的 MySQL performance_schema，能針對許多重要伺服器資源 (例如記憶體配置、預存程式、中繼資料鎖定等) 提供檢測功能。不過，performance_schema 包含超過 80 個資料表，且通常需要聯結 performance_schema 內的資料表以及 information_schema 中的資料表，才能取得所需的資訊。 在performance_schema和information_schema的基礎上，sys_schema在唯讀資料庫中提供功能強大的用戶易記檢視集合，並在 適用於 MySQL 的 Azure 資料庫 彈性伺服器 5.7 版中完全啟用。
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 秒。
因為 適用於 MySQL 的 Azure 資料庫 彈性伺服器會隨著記憶體調整 IO，因此在將布建的記憶體增加到 1 TB 之後，IO 延遲會減少到 571 毫秒。
sys.schema_tables_with_full_table_scans
儘管經過仔細規劃，許多查詢仍可能導致完整資料表掃描。 如需索引類型以及如何優化索引的詳細資訊，請參閱這篇文章：使用 EXPLAIN 來分析 適用於 MySQL 的 Azure 資料庫 - 彈性伺服器的查詢效能。 完整資料表掃描會耗用大量資源，並降低資料庫效能。 透過完整資料表掃描來尋找資料表的最快方式是查詢 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 檢視。
從上圖可以明顯看出，除了系統資料表和檢視以外，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 資料庫 彈性伺服器實例中利用這項功能。