sql >> Database >  >> RDS >> Mysql

Tips voor het afstemmen van MySQL-prestaties om de database te optimaliseren

Structured Query Language (SQL) is een speciale programmeertaal die wordt gebruikt voor het opslaan, manipuleren en ophalen van gegevens uit de database. Het heeft toepassingen gevonden in veel relationele databasesystemen, waaronder MySQL, Postgres, Oracle, SQL Server en andere.

Door SQL-instructies te gebruiken, kunnen ontwikkelaars eenvoudig verschillende functionele databasebewerkingen uitvoeren, zoals het maken, bijwerken en verwijderen van gegevens.

Naarmate de datavolumes groeien en de technologie steeds complexer wordt, wordt het steeds belangrijker om MySQL-databases op de juiste manier te optimaliseren om de eindgebruiker een ervaring te bieden en de infrastructuurkosten te verlagen. Met MySQL-tools voor het afstemmen van prestaties kunnen databaseprofessionals snel knelpunten identificeren, onvoldoende bewerkingen aanpakken door de uitvoeringsplannen voor query's te beoordelen en raadspelletjes elimineren.

Met de toegevoegde complexiteit van groeiende datavolumes en steeds veranderende workloads, zijn afstemming van de databaseprestaties en MySQL-queryoptimalisatie nu noodzakelijk om het resourcegebruik en de systeemprestaties te maximaliseren.

Er zijn verschillende redenen die het afstemmen van SQL een beetje ingewikkeld maken voor ontwikkelaars. Ten eerste vereist het uitgebreide technische expertise om verschillende uitvoeringsplannen te schrijven en te begrijpen. Hoewel het schrijven van schone en volledige SQL-statements de verantwoordelijkheid is van degene die er grondige kennis van opdoet.

Naast de complexiteit is het afstemmen erg tijdrovend. Want wanneer je een groot aantal SQL-statements moet doorzoeken, brengt het een beetje onzekerheid met zich mee om uit te zoeken welke statements je moet aanpassen en welke je moet laten staan. En hoewel elke verklaring anders is, varieert hun afstemmingsaanpak ook afhankelijk van hun respectieve functionaliteiten.


Bereid u voor op de Core Web Vitals-update

Ebook om uw website te versnellen voordat u verkeer begint te verliezen.

Bedankt

Je lijst is onderweg naar je inbox.


In deze zelfstudie zal ik bespreken hoe u de MySQL-prestaties kunt verbeteren met behulp van enkele handige tips voor het afstemmen van prestaties. Laten we ze hieronder in detail bekijken:

De voordelen van MySQL prestatieafstemming

Het grote voordeel van het identificeren van de prestatiebepalende factor voor databases, stelt u in staat overprovisioning te voorkomen en de kosten te verlagen door uw servers de juiste grootte te geven. Het geeft u ook inzicht in de vraag of het verplaatsen van gegevensopslag of het toevoegen van servercapaciteit de prestaties zal verbeteren of niet, en zo ja, hoeveel dit zal zijn.

De afstemmingsdatabase voor optimalisatie van MySQL-queryprestaties heeft geen bleke uitdagingen. Als de database eenmaal goed is afgesteld, geeft hij echter waardevolle prestatieresultaten met geweldige functionaliteiten. Het vermindert niet alleen ongewenste taakbelasting, maar optimaliseert ook de MySQL-database voor sneller ophalen van gegevens.

Misschien vind je dit ook leuk: PHP-prestatietips om uw websites te optimaliseren

Optimaliseer zoekopdrachten met MySQL-richtlijnen voor zoekopdrachtoptimalisatie

Volg deze best practices voor het afstemmen van MySQL-prestaties en het optimaliseren van de databasesnelheid.

Zorg allereerst voor indexering van alle predikaten in de clausules WHERE, JOIN, ORDER BY en GROUP BY. WebSphere Commerce legt sterk de nadruk op het indexeren van predikaten om de SQL-prestaties te verbeteren. Omdat onjuiste indexering van SQL-query's tabelscans kan veroorzaken, wat uiteindelijk kan leiden tot vergrendelingsproblemen en andere problemen.

Daarom raad ik ten zeerste aan om alle predikaatkolommen te indexeren, zodat de database MySQL-queryoptimalisatie kan ervaren.

Misschien vind je dit ook leuk: Handleiding voor optimalisatie van Laravel-prestaties

Vermijd het gebruik van functies in predikaten

De database gebruikt geen index als er een functie voorgedefinieerd is in de kolom.

Bijvoorbeeld:

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

Vanwege de UPPER()-functie gebruikt de database de index op COL1 niet. Als er geen manier is om die functie in SQL te vermijden, moet u een nieuwe functiegebaseerde index maken of aangepaste kolommen in de database genereren om de prestaties te verbeteren.

Vermijd het gebruik van een jokerteken (%) aan het begin van een predikaat

Het predikaat LIKE '%abc' veroorzaakt een volledige tabelscan. Bijvoorbeeld:

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

In de meeste gevallen brengt dit gebruik van jokertekens grote prestatiebeperkingen met zich mee.

Vermijd onnodige kolommen in de SELECT-clausule

In plaats van 'SELECT *' te gebruiken, geeft u altijd kolommen op in de SELECT-component om de MySQL-prestaties te verbeteren. Omdat onnodige kolommen extra belasting van de database veroorzaken, waardoor de prestaties en het hele systematische proces worden vertraagd.

Gebruik indien mogelijk inner join, in plaats van outer join

Gebruik outer join alleen als dat nodig is. Het onnodig gebruiken ervan beperkt niet alleen de databaseprestaties, maar beperkt ook de MySQL-queryoptimalisatie-opties, wat resulteert in een langzamere uitvoering van SQL-instructies.

Gebruik DISTINCT en UNION alleen als dat nodig is

Het gebruik van UNION- en DISTINCT-operatoren zonder enig belangrijk doel veroorzaakt ongewenste sortering en vertraging van de uitvoering van SQL. In plaats van UNION zorgt het gebruik van UNION ALL voor meer efficiëntie in het proces en betere MySQL-prestaties.

De ORDER BY-clausule is verplicht in SQL als u een gesorteerd resultaat verwacht

Het ORDER BY-sleutelwoord sorteert de resultatenset in vooraf gedefinieerde instructiekolommen. Hoewel de instructie voordeel oplevert voor de databasebeheerders voor het verkrijgen van de gesorteerde gegevens, produceert het ook een beetje prestatie-impact bij de SQL-uitvoering. Omdat de query eerst de gegevens moet sorteren om de uiteindelijke resultatenset te produceren, wat een beetje complexe bewerking veroorzaakt in de SQL-uitvoering.

Misschien vind je dit ook leuk: Twee tabellen samenvoegen in MySQL

Gebruik MySQL niet als wachtrij

Wachtrijen kunnen de prestaties van uw database vanaf de kern beïnvloeden en kunnen zonder uw medeweten in uw app-databases worden ingevoerd. Als u bijvoorbeeld een status voor een bepaald item instelt zodat een 'relevant proces' er toegang toe heeft, creëert u onbedoeld een wachtrij. Wat het doet, is dat het extra laadtijd opbouwt om toegang te krijgen tot de bron zonder enige belangrijke reden.

Wachtrijen veroorzaken problemen om twee belangrijke redenen. Ze rangschikken uw werklast, waardoor de parallelle voltooiing van taken wordt voorkomen, en ze resulteren vaak in een tabel met onderhanden werk en historische gegevens van reeds voltooide taken. Het voegt niet alleen latentie toe aan de applicatie, maar vormt ook een belemmering voor het afstemmen van MySQL-prestaties.

Misschien vind je dit ook leuk: Redis gebruiken voor wachtrijen

De vier fundamentele bronnen begrijpen

U hebt vier fundamentele bronnen nodig om databasefuncties te maken. CPU, schijf, geheugen en netwerk. Als een van deze niet correct werkt, heeft dit uiteindelijk invloed op de databaseserver en resulteert dit in slechte prestaties.

Om de fundamentele bronnen goed te begrijpen, moet u zich op twee specifieke gebieden concentreren, namelijk het kiezen van de juiste hardware en het oplossen van problemen ermee.

Zorg er altijd voor dat u allround prestatiecomponenten gebruikt bij het kiezen van hardware voor de MySQL-database. Kies niet alleen voor de beste van de stapel, maar zorg er ook voor dat er de juiste balans tussen is. We hebben vaak gezien dat organisaties de neiging hebben om servers met snelle CPU's en grote schijven te selecteren, maar ze vergissen zich met uitgehongerd geheugen, wat uiteindelijk ten koste gaat van de prestaties.

In sommige scenario's wordt het toevoegen van geheugen zeer substantieel voor het verbeteren van de prestaties als het gaat om de omvang. Het ziet er een beetje contra-intuïtief uit, maar in de meeste gevallen heeft het overbenutting van schijven rechtstreeks invloed op de databaseprestaties. Omdat het gebrek aan voldoende geheugen om de gegevens van de server op te slaan kostbaar blijkt te zijn in het ontsporen van de databaseprestaties.

Houd bij het oplossen van problemen altijd de prestaties van alle vier de fundamentele bronnen in de gaten. Valideer kwalitatief dat ze presteren volgens de behoeften aan verbetering in de normen. Door deze audit regelmatig in overweging te nemen, worden grote problemen snel opgelost.

Pagineringsquery's

Toepassingen die pagineren hebben de neiging om de server plat te leggen. Door u een pagina met resultaten te tonen, met een link om naar de volgende pagina te gaan, groeperen en sorteren deze toepassingen doorgaans op manieren die geen indexen kunnen gebruiken, en ze gebruiken een LIMIT- en offset-functie die ervoor zorgt dat de server veel doet werk genereren en vervolgens rijen weggooien.

U kunt optimalisaties vinden in de gebruikersinterface zelf. In plaats van het exacte aantal pagina's in de resultaten en links naar een individuele pagina weer te geven, kunt u gewoon een link naar de volgende pagina tonen. Je kunt ook voorkomen dat mensen naar irrelevante pagina's gaan.

Aan de queryzijde kunt u, in plaats van LIMIT met offset te gebruiken, één rij meer selecteren dan u nodig heeft, en wanneer de gebruiker op de link "volgende pagina" klikt, kunt u die laatste rij aanwijzen als het startpunt voor de volgende reeks resultaten . Als de gebruiker bijvoorbeeld een pagina met rijen 101 tot en met 120 heeft bekeken, moet u ook rij 121 selecteren; om de volgende pagina weer te geven, vraagt ​​u de server naar rijen groter dan of gelijk aan 121, limiet 21.

MySQL-subquery's optimaliseren

Het belangrijkste advies dat ik je kan geven over subquery's is dat je waar mogelijk de voorkeur moet geven aan een join, in ieder geval in de huidige versies van MySQL.

Subquery's zijn het onderwerp van intensief werk door het optimalisatieteam, en toekomstige versies van MySQL kunnen meer subquery-optimalisaties hebben. Houd wel in de gaten welke van de optimalisaties in de vrijgegeven code terechtkomen en hoeveel verschil ze zullen maken. Mijn punt hier is dat "prefereer een join" geen toekomstbestendig advies is. De server wordt steeds slimmer en de gevallen waarin je hem moet vertellen hoe hij iets moet doen in plaats van welke resultaten hij moet retourneren, worden steeds minder.

Mysql-querycache

Een van de belangrijkste aspecten van het meten van prestaties is het cachen van de inhoud. MySQL biedt databasequerycaching die de SELECT-instructietekst en het opgehaalde resultaat in de cache opslaat. Daarom, wanneer u een dubbele database maakt, roept u MySQL-querycache aan, deze zal op u reageren en het resultaat van de cache tonen, en geen enkele oproep zal herhaaldelijk worden geparseerd. Op deze manier kunt u het optimalisatieproces van de MySQL-cache maximaliseren.

Om MySQL-querycache in te stellen, moet u een paar instellingen aan MySQL toevoegen. Allereerst moet u controleren of de querycache beschikbaar is of niet met het volgende commando:

mysql> SHOW VARIABLES LIKE 'have_query_cache';

Dit toont het resultaat, JA. Dit betekent dat de MySQL-cache goed werkt.

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

| Variable_name    | Value |

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

| have_query_cache | YES   |

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

Nu kunt u de grootte en het type van de MySQL-querycache instellen. Onthoud dat de minimale standaardgrootte 40 KB is. De maximale grootte kan 32 MB zijn. U kunt de MySQL-query_cache_size instellen met de volgende opdracht:

mysql> SET GLOBAL query_cache_size = 40000;

Querycachetype kan het gedrag van alle verbindingen bepalen. U kunt de Query-cache ook uitschakelen voor query's zoals:

mysql> SET SESSION query_cache_type = OFF;

U kunt ook waarden instellen zoals 0,1 en 2 voor het instellen van de verbindingsstatus.

Memcached gebruiken voor MySQL-caching

Memcached is een gedistribueerd geheugencachingsysteem. Het versnelt websites met grote dynamische databases door het databaseobject op te slaan in Dynamic Memory om de druk op een server te verminderen, telkens wanneer een externe gegevensbron om een ​​lezing vraagt. Een Memcached-laag vermindert het aantal keren dat de database een verzoek doet.

Memcached slaat de waarden (v) op met de sleutel (k), en haalt de waarden (v) op met de sleutel (k) zonder zelfs de databasequery's te ontleden en blijft weg van al deze rompslomp.

Om meer te lezen over Memcache, kun je de handleiding lezen over het instellen van Memcache in php.

Afronden!

Dit artikel bevat in detail het verslag van de best practices voor database-optimalisatie en handige MySQL-tips voor het afstemmen van prestaties die elke ontwikkelaar moet kennen. Het is een complete gids voor die backend-ontwikkelaars, die onzeker zijn over hun slechte databaseprestaties en een aantal handige technieken nodig hebben om de MySQL-database vanuit de kern te optimaliseren.

Als u uw mening over het onderwerp wilt toevoegen of er vragen over wilt stellen, kunt u uw opmerkingen in het opmerkingengedeelte schrijven.


  1. Extraheer de maand van een datum in PostgreSQL

  2. Overmatige MySQL-activiteit

  3. Externe sleutels instellen in phpMyAdmin?

  4. De prijs van niet zuiveren