Prestaties afstemmen en databases onderhouden in Azure Database for MySQL - Flexible Server met behulp van de sys_schema

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - Enkele server Azure Database for MySQL - Flexibele server

Belangrijk

Azure Database for MySQL enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar een flexibele Azure Database for MySQL-server. Zie Wat gebeurt er met Azure Database for MySQL Enkele server voor meer informatie over migreren naar Azure Database for MySQL Flexibele server ?

De MySQL-performance_schema, voor het eerst beschikbaar in MySQL 5.5, biedt instrumentatie voor veel essentiële serverresources, zoals geheugentoewijzing, opgeslagen programma's, vergrendeling van metagegevens, enzovoort. De performance_schema bevat echter meer dan 80 tabellen en het ophalen van de benodigde informatie vereist vaak het samenvoegen van tabellen in de performance_schema en tabellen uit de information_schema. Voortbouwend op zowel performance_schema als information_schema, biedt de sys_schema een krachtige verzameling gebruiksvriendelijke weergaven in een alleen-lezen database en is volledig ingeschakeld in Azure Database for MySQL flexibele server versie 5.7.

Views of sys_schema.

Er zijn 52 weergaven in de sys_schema en elke weergave heeft een van de volgende voorvoegsels:

  • Host_summary of I/O: I/O-gerelateerde latenties.
  • InnoDB: InnoDB-bufferstatus en -vergrendelingen.
  • Geheugen: geheugengebruik door de host en gebruikers.
  • Schema: Schemagerelateerde informatie, zoals automatisch verhogen, indexen, enzovoort.
  • Instructie: informatie over SQL-instructies; dit kan een instructie zijn die heeft geresulteerd in een volledige tabelscan of lange querytijd.
  • Gebruiker: Verbruikte resources en gegroepeerd op gebruikers. Voorbeelden zijn bestands-I/Os, verbindingen en geheugen.
  • Wacht: Wachtgebeurtenissen gegroepeerd op host of gebruiker.

Laten we nu eens kijken naar enkele algemene gebruikspatronen van de sys_schema. Om te beginnen groeperen we de gebruikspatronen in twee categorieën: Prestaties afstemmen en databaseonderhoud.

Prestaties afstemmen

sys.user_summary_by_file_io

IO is de duurste bewerking in de database. We kunnen de gemiddelde IO-latentie achterhalen door een query uit te voeren op de sys.user_summary_by_file_io weergave. Met de standaard 125 GB ingerichte opslag is mijn IO-latentie ongeveer 15 seconden.

IO latency: 125 GB.

Omdat Azure Database for MySQL flexibele server IO schaalt met betrekking tot opslag, vermindert mijn IO-latentie na het verhogen van mijn ingerichte opslag tot 1 TB tot 571 ms.

IO latency: 1TB.

sys.schema_tables_with_full_table_scans

Ondanks een zorgvuldige planning kunnen veel query's nog steeds leiden tot volledige tabelscans. Raadpleeg dit artikel voor meer informatie over de typen indexen en hoe u deze kunt optimaliseren: problemen met queryprestaties oplossen. Volledige tabelscans zijn resource-intensief en verminderen de prestaties van uw database. De snelste manier om tabellen met een volledige tabelscan te vinden, is door een query uit te voeren op de sys.schema_tables_with_full_table_scans weergave.

Full table scans.

sys.user_summary_by_statement_type

Als u problemen met databaseprestaties wilt oplossen, kan het handig zijn om de gebeurtenissen in uw database te identificeren en de sys.user_summary_by_statement_type weergave te gebruiken, kan dit de truc zijn.

Summary by statement.

In dit voorbeeld heeft Azure Database for MySQL Flexibele server 53 minuten besteed aan het leegmaken van het langzame querylogboek 44579 keer. Dat is lang en veel IOs. U kunt deze activiteit verminderen door het logboek voor langzame query's uit te schakelen of door de frequentie van trage aanmelding bij query's naar Azure Portal te verlagen.

Databaseonderhoud

sys.innodb_buffer_stats_by_table

[! BELANGRIJK]

Het uitvoeren van query's op deze weergave kan van invloed zijn op de prestaties. Het wordt aanbevolen om deze probleemoplossing uit te voeren tijdens daluren.

De InnoDB-buffergroep bevindt zich in het geheugen en is het belangrijkste cachemechanisme tussen dbms en opslag. De grootte van de InnoDB-buffergroep is gekoppeld aan de prestatielaag en kan niet worden gewijzigd, tenzij er een andere product-SKU wordt gekozen. Net als bij geheugen in uw besturingssysteem worden oude pagina's verwisseld om ruimte te maken voor nieuwere gegevens. Als u wilt achterhalen welke tabellen het meeste geheugen van de InnoDB-buffergroep gebruiken, kunt u een query uitvoeren op de sys.innodb_buffer_stats_by_table weergave.

InnoDB buffer status.

In de bovenstaande afbeelding is het duidelijk dat andere dan systeemtabellen en weergaven, elke tabel in de mysqldatabase033-database, die als host fungeert voor een van mijn WordPress-sites, 16 kB of 1 pagina in beslag neemt van gegevens in het geheugen.

Sys.schema_unused_indexes en sys.schema_redundant_indexes

Indexen zijn uitstekende hulpmiddelen om de leesprestaties te verbeteren, maar er worden wel extra kosten in rekening gebracht voor invoegingen en opslag. Sys.schema_unused_indexes en sys.schema_redundant_indexes inzicht geven in ongebruikte of dubbele indexen.

Unused indexes.

Redundant indexes.

Conclusie

Kortom, de sys_schema is een uitstekend hulpprogramma voor het afstemmen van prestaties en het onderhoud van databases. Zorg ervoor dat u gebruik maakt van deze functie in uw flexibele serverexemplaren van Azure Database for MySQL.

Volgende stappen

  • Als u peerantwoorden wilt vinden op uw meest bezorgde vragen of een nieuw vraag/antwoord wilt posten, gaat u naar Stack Overflow.