Structured Query Language (SQL) är ett speciellt programmeringsspråk som används för att lagra, manipulera och hämta data från databasen. Den har hittat applikationer i många relationsdatabassystem inklusive MySQL, Postgres, Oracle, SQL Server och andra.
Genom att använda SQL-satser kan utvecklare enkelt utföra olika funktionella databasoperationer som att skapa, uppdatera och ta bort data.
När datavolymerna växer och tekniken blir allt mer komplex, blir det viktigare att optimera MySQL-databaser ordentligt för att leverera slutanvändarupplevelser och för att sänka infrastrukturkostnaderna. MySQL prestandajusteringsverktyg kan hjälpa databasproffs att snabbt identifiera flaskhalsar, inrikta sig på otillräckliga operationer genom en granskning av utförandeplaner för frågor och eliminera alla gissningsspel.
Med den extra komplexiteten av växande datavolymer och ständigt föränderliga arbetsbelastningar, är justering av databasprestanda och MySQL-frågeoptimering nu nödvändiga för att maximera resursutnyttjande och systemprestanda.
Det finns flera skäl som gör SQL-inställning lite komplex för utvecklare. För det första kräver det omfattande teknisk expertis att skriva och förstå olika genomförandeplaner. När du skriver rena och fullständiga SQL-satser är ansvaret för den som skaffar sig grundlig kunskap om det.
Förutom dess komplexitet är tuning mycket tidskrävande. För när du har ett stort antal SQL-satser att sortera i, medför det lite osäkerhet att ta reda på vilka satser du måste finjustera och vilken du ska lämna. Och även om alla uttalanden är olika, varierar deras inställningsmetod också beroende på deras respektive funktionalitet.
Gör dig redo för Core Web Vitals Update
E-bok för att snabba upp din webbplats innan du börjar tappa trafik.
Tack
Din lista är på väg till din inkorg.
I den här handledningen kommer jag att diskutera hur man förbättrar MySQL-prestandan med hjälp av några praktiska prestationsjusteringstips. Så låt oss se dem i detalj nedan:
Fördelarna med MySQL prestandajustering
Den stora fördelen med att identifiera den prestandadrivande faktorn för databasen gör att du kan undvika överprovisionering och minska kostnaderna genom att anpassa dina servrar i rätt storlek. Det ger dig också insikter om huruvida flytta datalagring eller lägga till serverkapacitet kommer att förbättra prestanda eller inte, och i så fall hur mycket det blir.
Inställningsdatabasen för optimering av MySQL-frågeprestanda kommer inte med bleka utmaningar. Men när den väl är inställd på rätt sätt ger databasen värdefulla prestandaresultat med fantastiska funktioner. Det minskar inte bara oönskad uppgiftsbelastning utan optimerar också MySQL-databasen för snabbare datahämtning.
Du kanske också gillar: PHP-prestandatips för att optimera dina webbplatser
Optimera frågor med MySQL Query Optimization Riktlinjer
Följ dessa bästa metoder för att ställa in din MySQL-prestanda och optimera databashastighet.
Se först och främst till att indexera alla predikaten i WHERE-, JOIN-, ORDER BY- och GROUP BY-satserna. WebSphere Commerce lägger stor vikt vid indexering av predikat för att öka SQL-prestanda. Eftersom felaktig indexering av SQL-frågor kan orsaka tabellsökningar, vilket så småningom leder till låsningsproblem och andra problem.
Därför rekommenderar jag starkt att indexera alla predikatkolumner så att databasen kan uppleva MySQL-frågeoptimering.
Du kanske också gillar: Laravels prestationsoptimeringsguide
Undvik att använda funktioner i predikat
Databasen använder inte ett index om den har någon funktion fördefinierad i kolumnen.
Till exempel:
SELECT * FROM TABLE1 WHERE UPPER(COL1)='ABC'Copy
På grund av UPPER()-funktionen använder databasen inte indexet på COL1. Om det inte finns något sätt att undvika den funktionen i SQL, måste du skapa ett nytt funktionsbaserat index eller skapa anpassade kolumner i databasen för att förbättra prestandan.
Undvik att använda jokertecken (%) i början av ett predikat
Predikatet LIKE '%abc' orsakar en fullständig tabellskanning. Till exempel:
SELECT * FROM TABLE1 WHERE COL1 LIKE '%ABC'Copy
I de flesta fall medför denna användning av jokertecken stora prestandabegränsningar.
Undvik onödiga kolumner i SELECT-satsen
Istället för att använda 'SELECT *', ange alltid kolumner i SELECT-satsen för att förbättra MySQL-prestandan. Eftersom onödiga kolumner orsakar extra belastning på databasen, vilket saktar ner dess prestanda och hela den systematiska processen.
Använd inre koppling, istället för yttre koppling om möjligt
Använd endast ytterskarv när det är nödvändigt. Att använda det i onödan begränsar inte bara databasprestanda utan begränsar också MySQL-frågeoptimeringsalternativ, vilket resulterar i långsammare exekvering av SQL-satser.
Använd endast DISTINCT och UNION om det är nödvändigt
Att använda UNION- och DISTINCT-operatorer utan något större syfte orsakar oönskad sortering och saktar ner SQL-exekveringen. Istället för UNION ger användning av UNION ALL mer effektivitet i processen och förbättrar MySQL-prestandan mer exakt.
ORDER BY-satsen är obligatorisk i SQL om du förväntar dig att få ett sorterat resultat
Nyckelordet ORDER BY sorterar resultatuppsättningen i fördefinierade satskolumner. Även om uttalandet medför fördelar för databasadministratörerna för att få sorterad data, ger den också lite prestandapåverkan i SQL-körningen. Eftersom frågan först måste sortera data för att producera den slutliga resultatuppsättningen, vilket orsakar en lite komplex operation i SQL-körningen.
Du kanske också gillar: Hur man går med två tabeller i MySQL
Använd inte MySQL som kö
Köer kan påverka din databasprestanda direkt från kärnan och kan komma in i dina appdatabaser utan din vetskap. Om du till exempel ställer in en status för ett visst objekt så att en "relevant process" kan komma åt det, skapar du oavsiktligt en kö. Vad den gör är att den bygger upp extra laddningstid för att komma åt resursen utan någon större anledning.
Köer orsakar problem av två huvudorsaker. De serialiserar din arbetsbelastning, förhindrar att uppgifter slutförs parallellt, och de resulterar ofta i en tabell som innehåller pågående arbete såväl som historiska data från redan avslutade jobb. Det lägger inte bara till latens till applikationen utan lägger också till hinder för MySQL-prestandanställningen.
Du kanske också gillar: Så här använder du Redis för att köa
Förstå de fyra grundläggande resurserna
Du behöver fyra grundläggande resurser för att skapa databasfunktioner. CPU, disk, minne och nätverk. Om någon av dessa inte fungerar korrekt påverkar det i slutändan databasservern och resulterar i dålig prestanda.
För att förstå de grundläggande resurserna ordentligt måste du fokusera på två särskilda områden, det vill säga att välja rätt hårdvara och felsöka problem med den.
Se alltid till att använda allsidiga prestandakomponenter när du väljer hårdvara för MySQL-databasen. Välj inte bara det bästa bland stacken utan se också till att det ska finnas rätt balans mellan dem. Vi har ofta sett att organisationer tenderar att välja servrar med snabba processorer och stora diskar, men de missförstås med svält minne som så småningom dödar prestandan.
I vissa scenarier blir det mycket viktigt att lägga till minne för att förbättra prestandan när det kommer till storleken. Det ser lite kontraintuitivt ut, men i de flesta fall påverkar överanvändningen av diskar direkt databasens prestanda. Eftersom bristen på tillräckligt med minne för att hålla serverns data visar sig vara kostsam när det gäller att spåra ur databasens prestanda.
När det gäller felsökning, håll alltid kontroll över prestanda för alla fyra grundläggande resurser. Validera kvalitativt att de presterar enligt kraven på förbättringar i normerna. Att regelbundet ta denna granskning i beaktande kommer snabbt att lösa stora förekommande problem.
Sökfrågor
Applikationer som paginerar tenderar att ta ner servern. Genom att visa dig en sida med resultat, med en länk för att gå till nästa sida, grupperar och sorterar dessa applikationer vanligtvis på sätt som inte kan använda index, och de använder en LIMIT- och offset-funktion som får servern att göra mycket arbetsgenererande och sedan kasta rader.
Du kan hitta optimeringar i själva användargränssnittet. Istället för att visa exakt antal sidor i resultaten och länkar till en enskild sida kan du bara visa en länk till nästa sida. Du kan också hindra människor från att gå till irrelevanta sidor.
På frågesidan, istället för att använda LIMIT med offset, kan du välja en rad mer än du behöver, och när användaren klickar på länken "nästa sida" kan du ange den sista raden som startpunkten för nästa uppsättning resultat . Till exempel, om användaren har visat en sida med raderna 101 till 120, måste du också välja rad 121; för att rendera nästa sida skulle du fråga servern efter rader större än eller lika med 121, gräns 21.
Optimera MySQL-underfrågor
Det viktigaste rådet jag kan ge dig om delfrågor är att du måste föredra en join där det är möjligt, åtminstone i nuvarande versioner av MySQL.
Delfrågor är föremål för intensivt arbete av optimerarteamet, och kommande versioner av MySQL kan ha fler subquery-optimeringar. Håll koll på vilka av optimeringarna som kommer att hamna i släppt kod och hur stor skillnad de kommer att göra. Min poäng här är att "föredrar en gå med" inte är ett framtidssäkert råd. Servern blir smartare hela tiden, och fallen där du måste berätta för den hur den ska göra något istället för vilka resultat som ska returneras blir färre.
Mysql Query Cache
En av de viktigaste aspekterna av att mäta prestanda är cachelagring av innehållet. MySQL tillhandahåller databasfrågecache som cachar SELECT-satstexten och det hämtade resultatet. Därför, när du gör en duplicerad databas, anropar du MySQL query cache, den kommer att svara dig och visa resultatet från cachen, och inget anrop kommer att analyseras upprepade gånger. På detta sätt kan du maximera MySQL-cacheoptimeringsprocessen.
För att ställa in MySQL-frågecache måste du lägga till några inställningar i MySQL. Först och främst måste du kontrollera om frågecache är tillgänglig eller inte med följande kommando:
mysql> SHOW VARIABLES LIKE 'have_query_cache';
Detta kommer att visa resultatet, JA. Detta betyder att MySQL-cachen fungerar bra.
+------------------+-------+ | Variable_name | Value | +------------------+-------+ | have_query_cache | YES | +------------------+-------+
Nu kan du ställa in storleken och typen av MySQL-frågecache. Kom ihåg att den minsta standardstorleken är 40 KB. Den maximala storleken kan vara 32MB. Du kan ställa in MySQL query_cache_size genom att använda följande kommando:
mysql> SET GLOBAL query_cache_size = 40000;
Frågecachetyp kan bestämma beteendet för alla anslutningar. Du kan också inaktivera Query-cachen för frågor som:
mysql> SET SESSION query_cache_type = OFF;
Du kan också ställa in värden som 0,1 och 2 för att ställa in anslutningsstatus.
Använd Memcached för MySQL-cache
Memcached är ett distribuerat minnescachesystem. Det snabbar upp webbplatser som har stora dynamiska databaser genom att lagra databasobjekt i Dynamic Memory för att minska trycket på en server, närhelst en extern datakälla begär en läsning. Ett Memcached lager minskar antalet gånger databasen gör en begäran.
Memcached lagrar värdena (v) med nyckeln (k), och hämtar värdena (v) med nyckeln (k) utan att ens analysera databasfrågorna och håller sig borta från alla dessa krångel.
För att läsa mer om Memcached kan du läsa guiden om hur du ställer in Memcache i php.
Avsluta!
Den här artikeln ger i detalj redogörelsen för de bästa metoderna för databasoptimering och praktiska tips för MySQL-prestandajustering som varje utvecklare måste känna till. Det är en komplett guide för de backend-utvecklare som är osäkra på sin dåliga databasprestanda och behöver några praktiska tekniker för att optimera MySQL-databasen från kärnan.
Om du vill lägga till dina tankar om ämnet eller vill ställa några frågor angående det, skriv gärna dina kommentarer i kommentarsfältet.