Optimering av datasamplingsfrekvens

6.1 Inledning

Låt oss nu gå från teori till praktik.

Vi lever i den verkliga världen och alla mjukvaruprodukter är i slutändan skapade för levande människor. Och dessa levande människor är väldigt irriterade på sajter som laddas långsamt och program som saktar ner.

Och om en databasfråga tar mer än en sekund är detta oacceptabelt . Användare kommer helt enkelt inte att använda en produkt som har sidor/funktionalitet som är så långsam.

Men ofta, för att visa en sida, måste du utföra flera dussin frågor till databasen. Och om de körs sekventiellt har du inte längre en andra gräns, utan låt oss säga 100 ms per begäran.

Här är de fem bästa sätten som programmerare påskyndar databasfrågor på:

1. Lägga till index till tabeller i databasen.
2. Omskrivning och optimering av frågor.
3. Aktivera (och konfigurera) cachelagring på databassidan.
4. Aktivera cachning på klientsidan.
5. Utför databasdenormalisering.

Du är redan bekant med alla dessa saker för det mesta, så följande kommer bara att vara praktiska råd.

6.2 Index

Det är ingen hemlighet att arbetet med en databas tar upp det mesta av arbetet på nästan vilken webbplats som helst. Och det är att arbeta med databasen som oftast är flaskhalsen för webbapplikationer.

I den här artikeln skulle jag vilja ge praktiska råd om hur du använder MySQL.

Jag säger genast:

• den här artikeln är skriven om MySQL, även om de allmänna sakerna sannolikt är sanna för alla DBMS.
• allt som står i artikeln är min personliga synvinkel och är inte den ultimata sanningen.
• råd låtsas inte vara nya och är resultatet av en generalisering av den lästa litteraturen och personliga erfarenheter.
• inom ramen för denna artikel kommer jag inte att beröra MySQL-konfigurationsproblem.

Problem vid användning av MySQL kan delas in i följande tre grupper (i viktordning):

1. Icke-användning eller missbruk av index.
2. Fel databasstruktur.
3. Felaktiga \ suboptimala SQL-frågor.

Låt oss ta en närmare titt på var och en av dessa grupper.

Använda index

Att inte använda eller missbruka index är det som oftast saktar ner frågorna. För dem som inte är bekanta med mekanismen för hur index fungerar eller ännu inte har läst om det i manualen, rekommenderar jag starkt att du läser den.

Tips för att använda index:

• Du behöver inte indexera allt . Ganska ofta, utan att förstå innebörden, indexerar folk helt enkelt alla fält i en tabell. Index påskyndar hämtningar, men saktar ner radinfogningar och uppdateringar, så valet av varje index måste vara meningsfullt.
• En av huvudparametrarna som kännetecknar indexet är selektivitet, som är antalet olika element i indexet. Det är ingen mening att indexera ett fält som har två eller tre möjliga värden. Det blir liten nytta av ett sådant index.
• Valet av index bör börja med en analys av alla frågor mot en given tabell. Mycket ofta, efter en sådan analys, istället för tre eller fyra index, kan du göra en sammansatt.
• När du använder sammansatta index är ordningen på fälten i indexet avgörande.
• Glöm inte att täcka index. Om all data i en fråga kan hämtas från ett index, så kommer MySQL inte direkt åt tabellen. Sådana förfrågningar kommer att utföras mycket snabbt. Till exempel, för en fråga SELECT name FROM user WHERE login='test'med ett index (inloggning, namn) krävs inte åtkomst till tabellen. Ibland är det vettigt att lägga till ett extra fält till ett sammansatt index, vilket kommer att göra indexet täckande och påskynda frågorna.
• För radindex räcker det ofta att endast indexera en del av raden. Detta kan avsevärt minska indexstorleken.
• Om %det är i början LIKE(SELECT * FROM table WHERE field LIKE '%test')kommer index inte att användas.
• FULLTEXT - indexet används endast med syntaxen MATCH ... MOT .

6.3 Databasstruktur

En väl utformad databas är nyckeln till ett snabbt och effektivt arbete med databasen. Å andra sidan är en dåligt utformad databas alltid en huvudvärk för utvecklare.

Databasdesigntips:

1. Använd minsta möjliga datatyper. Ju större datatyp, desto större tabell, desto fler diskåtkomster behövs för att få data. Använd en mycket bekväm procedur: SELECT * FROM table_name PROCEDURE ANALYSE();att bestämma minsta möjliga datatyper.
2. Observera normala former under konstruktionsfasen. Ofta tar programmerare till denormalisering redan i detta skede. Men i de flesta fall, i början av projektet, är det långt ifrån självklart hur detta kan resultera. Att avnormalisera en tabell är mycket lättare än att lida av en suboptimalt denormaliserad tabell. Och JOINibland fungerar det snabbare än felaktigt denormaliserade tabeller.
3. Använd inte NULLkolumner om du inte medvetet behöver dem.

6.4 SQL-frågor.

Lika ofta finns det en önskan att skriva om alla frågor i native SQL så att frågan blir så snabb som möjligt. Om du bestämmer dig för att göra detta, så här är några tips:

1. Undvik förfrågningar i en loop. SQL är ett språk för uppsättningar, och skrivfrågor bör inte hanteras på funktionsspråket, utan på uppsättningarnas språk.
2. Undvik *(asterisker) i frågor. Ange gärna exakt de fält du väljer. Detta kommer att minska mängden data som hämtas och skickas. Glöm inte heller att täcka index. Även om du väljer alla fält i tabellen är det bättre att lista dem. För det första förbättrar det kodens läsbarhet. När du använder asterisker är det omöjligt att ta reda på vilka fält som finns i tabellen utan att titta närmare på det. För det andra , idag har din tabell fem INT- kolumner, och en månad senare lades ytterligare en TEXT och BLOB till , och asterisken förblev som den var.
3. Vid sidnumrering, för att få det totala antalet poster, använd SQL_CALC_FOUND_ROWSoch SELECT FOUND_ROWS();When used SQL_CALC_FOUND_ROWS MySQL, cachar det valda antalet rader (innan LIMIT tillämpas), och när det används SELECT FOUND_ROWS()returnerar det endast detta cachade värde utan att behöva köra om frågan.
4. Glöm inte att det INSERTfinns en syntax för flera inlägg. En fråga kommer att köra en storleksordning snabbare än flera frågor i en loop.
5. Använd LIMITdär du inte behöver all data.
6. Använd INSERT… ON DUPLICATE KEY UPDATE…i stället för och INSERTeller UPDATEefter val, och ofta i stället för REPLACE.
7. Glöm inte denna fantastiska funktion GROUP_CONCAT. Det kan hjälpa till med komplexa frågor.