Sdílet prostřednictvím


Ladění výkonu a údržba databází na flexibilním serveru Azure Database for MySQL pomocí sys_schema

MySQL performance_schema, která je poprvé dostupná v MySQL 5.5, poskytuje instrumentaci pro mnoho důležitých serverových prostředků, jako je přidělení paměti, uložené programy, zamykání metadat atd. Performance_schema však obsahuje více než 80 tabulek a získání potřebných informací často vyžaduje spojování tabulek v rámci performance_schema a tabulky z information_schema. Sys_schema, která je založená na performance_schema i na information_schema, poskytuje výkonnou kolekci uživatelsky přívětivých zobrazení v databázi jen pro čtení a je plně povolená na flexibilním serveru Azure Database for MySQL verze 5.7.

Snímek obrazovky se zobrazeními sys_schema

V sys_schema je 52 zobrazení a každé zobrazení má jednu z následujících předpon:

  • Host_summary nebo vstupně-výstupní operace: Latence související s vstupně-výstupními operacemi
  • InnoDB: Stav vyrovnávací paměti InnoDB a zámky.
  • Paměť: Využití paměti hostitelem a uživateli.
  • Schéma: Informace související se schématem, například automatické přírůstky, indexy atd.
  • Příkaz: Informace o příkazech SQL; Může to být příkaz, který způsobil úplnou kontrolu tabulky nebo dlouhou dobu dotazování.
  • Uživatel: Prostředky spotřebované a seskupené podle uživatelů Příklady jsou vstupně-výstupní operace souborů, připojení a paměť.
  • Čekání: Události čekání seskupené podle hostitele nebo uživatele

Teď se podíváme na některé běžné vzory použití sys_schema. Abychom mohli začít, seskupíme vzorce použití do dvou kategorií: ladění výkonu a údržba databáze.

Ladění výkonu

sys.user_summary_by_file_io

Vstupně-výstupní operace je nejnákladnější operací v databázi. Průměrnou latenci vstupně-výstupních operací můžeme zjistit dotazem na zobrazení sys.user_summary_by_file_io . Ve výchozím nastavení 125 GB zřízeného úložiště je latence vstupně-výstupních operací přibližně 15 sekund.

Snímek obrazovky s latencí vstupně-výstupních operací: 125 GB

Vzhledem k tomu, že flexibilní server Azure Database for MySQL škáluje vstupně-výstupní operace s ohledem na úložiště, po zvýšení zřízeného úložiště na 1 TB se latence vstupně-výstupních operací sníží na 571 ms.

Snímek obrazovky s latencí vstupně-výstupních operací: 1 TB

sys.schema_tables_with_full_table_scans

I přes pečlivé plánování může mít mnoho dotazů stále za následek úplné prohledávání tabulek. Další informace o typech indexů a jejich optimalizaci najdete v tomto článku: Výkon dotazů profilu ve službě Azure Database for MySQL – Flexibilní server POMOCÍ funkce EXPLAIN. Úplné prohledávání tabulek je náročné na prostředky a snižuje výkon databáze. Nejrychlejší způsob, jak najít tabulky s úplnou kontrolou tabulek, je dotazování sys.schema_tables_with_full_table_scans zobrazení.

Snímek obrazovky s prohledáváním celé tabulky

sys.user_summary_by_statement_type

Pokud chcete vyřešit problémy s výkonem databáze, může být užitečné identifikovat události, ke kterým dochází uvnitř databáze, a použití zobrazení sys.user_summary_by_statement_type může udělat jenom trik.

Snímek obrazovky s příkazem Summary by

V tomto příkladu flexibilní server Azure Database for MySQL strávil 53 minut vyprázdněním protokolu pomalých dotazů 44579krát. To je dlouhá doba a mnoho IOSů. Tuto aktivitu můžete snížit tak, že zakážete protokol pomalých dotazů nebo snížíte frekvenci pomalého přihlášení k dotazům na webu Azure Portal.

Údržba databáze

sys.innodb_buffer_stats_by_table

[! DŮLEŽITÉ]

Dotazování na toto zobrazení může mít vliv na výkon. Toto řešení potíží doporučujeme provést mimo špičku.

Fond vyrovnávací paměti InnoDB se nachází v paměti a je hlavním mechanismem mezipaměti mezi DBMS a úložištěm. Velikost fondu vyrovnávacích pamětí InnoDB je svázaná s úrovní výkonu a nelze ji změnit, pokud není zvolena jiná skladová položka produktu. Stejně jako u paměti v operačním systému se staré stránky prohodí, aby se uvolnilo místo pro novější data. Pokud chcete zjistit, které tabulky spotřebovávají většinu paměti fondu vyrovnávací paměti InnoDB, můžete dotazovat sys.innodb_buffer_stats_by_table zobrazení.

Snímek obrazovky se stavem vyrovnávací paměti InnoDB

Na obrázku výše je zřejmé, že jiná než systémové tabulky a zobrazení, každá tabulka v databázi mysqldatabase033, která hostuje jeden z mých webů WordPress, zabírá 16 kB nebo 1 stránku dat v paměti.

Sys.schema_unused_indexes a sys.schema_redundant_indexes

Indexy jsou skvělé nástroje pro zvýšení výkonu čtení, ale za vložení a úložiště se účtují další náklady. Sys.schema_unused_indexes a sys.schema_redundant_indexes poskytují přehled o nepoužívaných nebo duplicitních indexech.

Snímek obrazovky s nepoužitými indexy

Snímek obrazovky s redundantními indexy

Závěr

Stručně řečeno, sys_schema je skvělý nástroj pro optimalizaci výkonu i údržbu databáze. Nezapomeňte využít výhod této funkce v instanci flexibilního serveru Azure Database for MySQL.

Další krok