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

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for MySQL – Jednoúčelový server Azure Database for MySQL

Důležité

Jednoúčelový server Azure Database for MySQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for MySQL. Další informace o migraci na flexibilní server Azure Database for MySQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for MySQL?

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. Díky performance_schema i information_schema poskytuje sys_schema 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.

Views of 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.

IO latency: 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.

IO latency: 1TB.

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 otypech Ú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í.

Full table scans.

sys.user_summary_by_statement_type

Při řešení potíží s výkonem databáze může být užitečné identifikovat události, ke kterým dochází v databázi, a použití zobrazení sys.user_summary_by_statement_type může udělat jenom trik.

Summary by statement.

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í.

InnoDB buffer status.

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.

Unused indexes.

Redundant indexes.

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 tuto funkci v instanci flexibilního serveru Azure Database for MySQL.

Další kroky

  • Pokud chcete najít partnerské odpovědi na nejčastější dotazy nebo publikovat novou otázku nebo odpověď, navštivte web Stack Overflow.