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

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 server version 5.7.

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.

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

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: Profilfrågasprestanda i Azure Database for MySQL – flexibel server med hjälp av EXPLAIN. 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.

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.

I det här exemplet tillbringade 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 Portal.

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.

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.

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 Azure Database for MySQL – flexibel serverinstans.

Gå vidare

Stack Overflow