sql >> Database teknologi >  >> RDS >> Mysql

MySQL Performance Tuning Tips til at optimere databasen

Structured Query Language (SQL) er et programmeringssprog til særlige formål, der bruges til at gemme, manipulere og hente data fra databasen. Det har fundet applikationer i mange relationelle databasesystemer, herunder MySQL, Postgres, Oracle, SQL Server og andre.

Ved at bruge SQL-sætninger kan udviklere nemt udføre forskellige funktionelle databaseoperationer, såsom oprettelse, opdatering og sletning af data.

Efterhånden som datamængderne vokser, og teknologien bliver mere og mere kompleks, bliver det vigtigere at optimere MySQL-databaser korrekt for at levere slutbrugeroplevelse og for at sænke infrastrukturomkostningerne. MySQL-ydeevnejusteringsværktøjer kan hjælpe databaseprofessionelle med hurtigt at identificere flaskehalse, målrette utilstrækkelige operationer gennem en gennemgang af forespørgselsudførelsesplaner og eliminere gættespil.

Med den ekstra kompleksitet af voksende datamængder og stadigt skiftende arbejdsbelastninger er tuning af databaseydeevne og MySQL-forespørgselsoptimering nu nødvendige for at maksimere ressourceudnyttelsen og systemets ydeevne.

Der er flere grunde, der gør SQL-tuning en smule kompleks for udviklere. For det første kræver det omfattende teknisk ekspertise at skrive og forstå forskellige udførelsesplaner. Mens du skriver rene og komplette SQL-sætninger, er ansvaret for den, der opnår grundig viden om det.

Udover kompleksiteten er tuning meget tidskrævende. For når man har et stort antal SQL-sætninger at sortere i, giver det en smule usikkerhed at finde ud af, hvilke sætninger man skal tune op, og hvilken man skal lade være. Og selvom hvert udsagn er forskelligt, varierer deres indstillingstilgang også i henhold til deres respektive funktionaliteter.


Gør dig klar til Core Web Vitals Update

E-bog for at fremskynde dit websted, før du begynder at miste trafik.

Tak

Din liste er på vej til din indbakke.


I denne tutorial vil jeg diskutere, hvordan man forbedrer MySQL-ydeevnen ved hjælp af nogle praktiske tip til justering af ydeevne. Så lad os se dem i detaljer nedenfor:

Fordelene ved MySQL Performance Tuning

Den største fordel ved at identificere den præstationsdrivende faktor for databasen giver dig mulighed for at undgå overprovisionering og reducere omkostningerne ved at tilpasse dine servere i den rigtige størrelse. Det giver dig også indsigt i, om flytning af datalagring eller tilføjelse af serverkapacitet vil medføre forbedringer i ydeevnen eller ej, og i så fald, hvor meget vil det være.

Tuningdatabasen til MySQL-forespørgselsydeevneoptimering kommer ikke med blege udfordringer. Men når databasen først er indstillet korrekt, giver den værdifulde resultater med fremragende funktionaliteter. Det sænker ikke kun uønsket opgavebelastning, men optimerer også MySQL-databasen for hurtigere datahentning.

Du kunne måske også lide: PHP Performance Tips til at optimere dine websteder

Optimer forespørgsler med MySQL-forespørgselsoptimeringsretningslinjer

Følg disse bedste fremgangsmåder for at justere din MySQL-ydeevne og optimere databasehastigheden.

Først og fremmest skal du sikre indeksering af alle prædikaterne i WHERE-, JOIN-, ORDER BY- og GROUP BY-sætningerne. WebSphere Commerce lægger stor vægt på indeksering af prædikater for at øge SQL-ydeevnen. Fordi forkert indeksering af SQL-forespørgsler kan forårsage tabelscanninger, som i sidste ende fører til låseproblemer og andre problemer.

Derfor anbefaler jeg stærkt at indeksere alle prædikatkolonner, så databasen kan opleve MySQL-forespørgselsoptimering.

Du kunne måske også lide: Laravel Performance Optimization Guide

Undgå at bruge funktioner i prædikater

Databasen bruger ikke et indeks, hvis den har en funktion foruddefineret i kolonnen.

For eksempel:

SELECT * FROM TABLE1 WHERE UPPER(COL1)='ABC'Copy

På grund af UPPER()-funktionen, bruger databasen ikke indekset på COL1. Hvis der ikke er nogen måde at undgå denne funktion i SQL, bliver du nødt til at oprette et nyt funktionsbaseret indeks eller være nødt til at generere brugerdefinerede kolonner i databasen for at forbedre ydeevnen.

Undgå at bruge et jokertegn (%) i begyndelsen af ​​et prædikat

Prædikatet LIKE '%abc' forårsager en fuld tabelscanning. For eksempel:

SELECT * FROM TABLE1 WHERE COL1 LIKE '%ABC'Copy

I de fleste tilfælde medfører denne brug af jokertegn store ydeevnebegrænsninger.

Undgå unødvendige kolonner i SELECT-sætning

I stedet for at bruge 'SELECT *' skal du altid angive kolonner i SELECT-sætningen for at forbedre MySQL-ydeevnen. Fordi unødvendige kolonner forårsager yderligere belastning af databasen, hvilket bremser dens ydeevne samt hele den systematiske proces.

Brug indre forbindelse, i stedet for ydre forbindelse, hvis det er muligt

Brug kun udvendig samling, når det er nødvendigt. Brugen af ​​det unødvendigt begrænser ikke kun databasens ydeevne, men begrænser også MySQL-forespørgselsoptimeringsmulighederne, hvilket resulterer i langsommere udførelse af SQL-sætninger.

Brug kun DISTINCT og UNION, hvis det er nødvendigt

Brug af UNION- og DISTINCT-operatører uden større formål forårsager uønsket sortering og opbremsning af SQL-udførelse. I stedet for UNION giver brug af UNION ALL mere effektivitet i processen og forbedrer MySQL-ydeevnen mere præcist.

ORDER BY-sætningen er obligatorisk i SQL, hvis du forventer at få et sorteret resultat

Nøgleordet ORDER BY sorterer resultatsættet i foruddefinerede sætningskolonner. Selvom sætningen giver databaseadministratorerne fordele for at få de sorterede data, giver den også en smule præstationspåvirkning i SQL-udførelsen. Fordi forespørgslen først skal sortere dataene for at producere det endelige resultatsæt, hvilket forårsager en lidt kompleks operation i SQL-udførelsen.

Du kunne måske også lide: Sådan forbinder du to borde i MySQL

Brug ikke MySQL som en kø

Køer kan påvirke din databaseydeevne lige fra kernen og kan komme ind i dine appdatabaser uden din viden. For eksempel, hvis du opretter en status for en bestemt vare, så en 'relevant proces' kan få adgang til den, opretter du utilsigtet en kø. Det, det gør, er, at det opbygger ekstra indlæsningstid for at få adgang til ressourcen uden nogen større grund.

Køer forårsager problemer af to hovedårsager. De serialiserer din arbejdsbyrde, forhindrer fuldførelse af opgaver parallelt, og de resulterer ofte i en tabel, der indeholder igangværende arbejde samt historiske data fra allerede udførte opgaver. Det tilføjer ikke kun latens til applikationen, men tilføjer også en hindring for MySQL-indstilling af ydeevne.

Du kunne måske også lide: Sådan bruges Redis til kø

Forstå de fire grundlæggende ressourcer

Du skal bruge fire grundlæggende ressourcer til at lave databasefunktioner. CPU, disk, hukommelse og netværk. Hvis nogen af ​​disse ikke fungerer korrekt, påvirker det i sidste ende databaseserveren og resulterer i dårlig ydeevne.

For at forstå de grundlæggende ressourcer korrekt, skal du fokusere på to særlige områder, nemlig at vælge den rigtige hardware og fejlfinde problemer med den.

Sørg altid for at bruge allround-ydelseskomponenter, når du vælger hardware til MySQL-databasen. Vælg ikke kun det bedste blandt stakken, men sørg også for, at der skal være den rigtige balance mellem dem. Vi har ofte set, at organisationer har en tendens til at vælge servere med hurtige CPU'er og store diske, men de bliver forvekslet med udsultet hukommelse, som til sidst dræber ydeevnen.

I nogle scenarier bliver tilføjelse af hukommelse meget væsentlig for at forbedre ydeevnen, når det kommer til størrelsen. Det ser lidt kontraintuitivt ud, men i de fleste tilfælde påvirker overudnyttelsen af ​​diske direkte databasens ydeevne. Da manglen på nok hukommelse til at opbevare serverens data viser sig at være bekostelig ved at afspore databasens ydeevne.

Når det kommer til fejlfinding, skal du altid holde styr på ydeevnen af ​​alle fire grundlæggende ressourcer. Validerer kvalitativt, at de udfører i henhold til behovsforbedring i normerne. Regelmæssig overvejelse af denne revision vil hurtigt løse større opståede problemer.

Søgeforespørgsler

Programmer, der paginerer, har en tendens til at bringe serveren ned. Ved at vise dig en side med resultater, med et link til at gå til næste side, grupperer og sorterer disse applikationer typisk på måder, der ikke kan bruge indekser, og de anvender en LIMIT og offset-funktion, der får serveren til at udføre en masse arbejdsgenerering og derefter kassering af rækker.

Du kan finde optimeringer i selve brugergrænsefladen. I stedet for at vise det nøjagtige antal sider i resultaterne og links til en individuel side, kan du blot vise et link til næste side. Du kan også forhindre folk i at gå til irrelevante sider.

På forespørgselssiden kan du i stedet for at bruge LIMIT med offset vælge en række mere, end du har brug for, og når brugeren klikker på linket "næste side", kan du udpege den sidste række som udgangspunkt for det næste sæt resultater . For eksempel, hvis brugeren har set en side med række 101 til 120, skal du også vælge række 121; for at gengive den næste side, skal du forespørge på serveren for rækker større end eller lig med 121, grænse 21.

Optimering af MySQL-underforespørgsler

Det vigtigste råd, jeg kan give dig om underforespørgsler, er, at du skal foretrække et join, hvor det er muligt, i hvert fald i de nuværende versioner af MySQL.

Underforespørgsler er genstand for intenst arbejde af optimeringsteamet, og kommende versioner af MySQL kan have flere underforespørgselsoptimeringer. Hold øje med, hvilke af optimeringerne der ender i frigivet kode, og hvor stor forskel de vil gøre. Min pointe her er, at "foretrækker en joinforbindelse" ikke er fremtidssikret rådgivning. Serveren bliver hele tiden klogere, og de tilfælde, hvor du skal fortælle den, hvordan den skal gøre noget i stedet for hvilke resultater, der skal returneres, bliver færre.

Mysql Query Cache

Et af de vigtigste aspekter ved måling af ydeevne er caching af indholdet. MySQL giver databaseforespørgselscache, som cacher SELECT-sætningsteksten og det hentede resultat. Derfor, når du laver en duplikatdatabase, ringer du til MySQL-forespørgselscachen, den vil svare dig og vise resultatet fra cachen, og intet opkald vil blive parset gentagne gange. På denne måde kan du maksimere MySQL-cache-optimeringsprocessen.

For at konfigurere MySQL-forespørgselscache skal du tilføje et par indstillinger til MySQL. Først og fremmest skal du kontrollere, om forespørgselscache er tilgængelig eller ej med følgende kommando:

mysql> SHOW VARIABLES LIKE 'have_query_cache';

Dette vil vise resultatet, JA. Dette betyder, at MySQL-cachen fungerer fint.

+------------------+-------+

| Variable_name    | Value |

+------------------+-------+

| have_query_cache | YES   |

+------------------+-------+

Nu kan du konfigurere MySQL-forespørgselscachestørrelsen og -typen. Husk den mindste standardstørrelse er 40KB. Den maksimale størrelse kan være 32MB. Du kan konfigurere MySQL query_cache_size ved at bruge følgende kommando:

mysql> SET GLOBAL query_cache_size = 40000;

Forespørgselscachetype kan bestemme adfærden for alle forbindelser. Du kan også deaktivere Query-cachen for forespørgsler som:

mysql> SET SESSION query_cache_type = OFF;

Du kan også indstille værdier som 0,1 og 2 til opsætning af forbindelsesstatus.

Brug Memcached til MySQL Caching

Memcached er et distribueret hukommelsescachesystem. Det fremskynder websteder med store dynamiske databaser ved at gemme databaseobjekter i Dynamic Memory for at reducere presset på en server, når en ekstern datakilde anmoder om en læsning. Et Memcached-lag reducerer antallet af gange, databasen foretager en anmodning.

Memcached gemmer værdierne (v) med nøglen (k), og henter værdierne (v) med nøglen (k) uden selv at analysere databaseforespørgslerne og holder sig væk fra alle disse besvær.

For at læse mere om Memcached kan du læse guiden til hvordan du opsætter Memcache i php.

Afslutning!

Denne artikel giver i detaljer beretningen om bedste praksis for databaseoptimering og praktiske MySQL-ydeevnejusteringstips, som enhver udvikler skal kende. Det er en komplet guide til de backend-udviklere, som er usikre på deres dårlige databaseydeevne og har brug for nogle praktiske teknikker til at optimere MySQL-databasen fra kernen.

Hvis du vil tilføje dine tanker om emnet eller vil stille nogle spørgsmål vedrørende det, er du velkommen til at skrive dine kommentarer i kommentarfeltet.


  1. SQLite JSON_VALID()

  2. Database korruption

  3. Tilslutning af Oracle til SQL Server fra Windows

  4. Forespørgsel efter element af array i JSON-kolonnen