Justera prestanda och underhålla databaser i Azure Database for MySQL – flexibel server med hjälp av sys_schema

  • Artikel

GÄLLER FÖR: Azure Database for MySQL – Azure Database for MySQL – enskild server – flexibel server

Viktigt!

Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med Azure Database for MySQL – enskild server?

MySQL-performance_schema, som först finns i MySQL 5.5, tillhandahåller instrumentation för många viktiga serverresurser som minnesallokering, lagrade program, metadatalåsning osv. Men performance_schema innehåller fler än 80 tabeller, och för att få nödvändig information krävs ofta sammanfogning av tabeller i performance_schema och tabeller från information_schema. Med både performance_schema och information_schema ger sys_schema en kraftfull samling användarvänliga vyer i en skrivskyddad databas och är helt aktiverad i Azure Database for MySQL – flexibel serverversion 5.7.

Views of sys_schema.

Det finns 52 vyer i sys_schema och varje vy har något av följande prefix:

  • Host_summary eller I/O: I/O-relaterade svarstider.
  • InnoDB: InnoDB-buffertstatus och lås.
  • Minne: Minnesanvändning av värden och användarna.
  • Schema: Schemarelaterad information, till exempel automatisk ökning, index osv.
  • Instruktion: Information om SQL-instruktioner; det kan vara en instruktion som resulterade i fullständig tabellgenomsökning eller lång frågetid.
  • Användare: Resurser som förbrukas och grupperas av användare. Exempel är fil-I/Os, anslutningar och minne.
  • Vänta: Vänta händelser grupperade efter värd eller användare.

Nu ska vi titta på några vanliga användningsmönster i sys_schema. Till att börja med grupperar vi användningsmönstren i två kategorier: Prestandajustering och databasunderhåll.

Prestandajustering

sys.user_summary_by_file_io

I/O är den dyraste åtgärden i databasen. Vi kan ta reda på den genomsnittliga I/O-svarstiden genom att fråga sys.user_summary_by_file_io vyn. Med standardvärdet 125 GB etablerad lagring är min I/O-svarstid cirka 15 sekunder.

IO latency: 125 GB.

Eftersom Azure Database for MySQL– flexibel server skalar I/O med avseende på lagring, efter att ha ökat min etablerade lagring till 1 TB, minskar min I/O-svarstid till 571 ms.

IO latency: 1TB.

sys.schema_tables_with_full_table_scans

Trots noggrann planering kan många frågor fortfarande resultera i fullständiga tabellgenomsökningar. Mer information om typer av index och hur du optimerar dem finns i den här artikeln: Så här felsöker du frågeprestanda. Fullständiga tabellgenomsökningar är resursintensiva och försämrar databasens prestanda. Det snabbaste sättet att hitta tabeller med fullständig tabellgenomsökning är att fråga sys.schema_tables_with_full_table_scans vy.

Full table scans.

sys.user_summary_by_statement_type

Om du vill felsöka problem med databasprestanda kan det vara bra att identifiera händelserna som händer i databasen, och att använda sys.user_summary_by_statement_type-vyn kan bara göra susen.

Summary by statement.

I det här exemplet spenderade Azure Database for MySQL flexibel server 53 minuter med att rensa den långsamma frågeloggen 44579 gånger. Det är en lång tid och många IO: er. Du kan minska den här aktiviteten genom att antingen inaktivera den långsamma frågeloggen eller minska frekvensen för långsam frågeinloggning till Azure-portalen.

Databasunderhåll

sys.innodb_buffer_stats_by_table

[! VIKTIGT]

Att köra frågor mot den här vyn kan påverka prestanda. Vi rekommenderar att du utför den här felsökningen under kontorstid utanför hög belastning.

InnoDB-buffertpoolen finns i minnet och är den huvudsakliga cachemekanismen mellan DBMS och lagring. Storleken på InnoDB-buffertpoolen är kopplad till prestandanivån och kan inte ändras om inte en annan produkt-SKU väljs. Precis som med minnet i operativsystemet växlas gamla sidor ut för att ge plats åt nyare data. Om du vill ta reda på vilka tabeller som förbrukar det mesta av InnoDB-buffertpoolens minne kan du fråga sys.innodb_buffer_stats_by_table vyn.

InnoDB buffer status.

I bilden ovan är det uppenbart att förutom systemtabeller och vyer upptar varje tabell i databasen mysqldatabase033, som är värd för en av mina WordPress-webbplatser, 16 KB, eller 1 sida, data i minnet.

Sys.schema_unused_indexes &sys.schema_redundant_indexes

Index är bra verktyg för att förbättra läsprestanda, men de medför ytterligare kostnader för infogningar och lagring. Sys.schema_unused_indexes och sys.schema_redundant_indexes ger insikter om oanvända eller duplicerade index.

Unused indexes.

Redundant indexes.

Slutsats

Sammanfattningsvis är sys_schema ett bra verktyg för både prestandajustering och databasunderhåll. Se till att dra nytta av den här funktionen i din flexibla Azure Database for MySQL-serverinstans.

Nästa steg

  • Om du vill hitta peer-svar på dina mest berörda frågor eller skicka en ny fråga/ett nytt svar kan du besöka Stack Overflow.