Optimering af datasamplinghastighed

6.1 Indledning

Lad os nu gå fra teori til praksis.

Vi lever i den virkelige verden, og alle softwareprodukter er i sidste ende skabt til levende mennesker. Og disse levende mennesker er meget irriterede over sider, der indlæses langsomt, og programmer, der bremser.

Og hvis en databaseforespørgsel tager mere end et sekund, er dette uacceptabelt . Brugere vil simpelthen ikke bruge et produkt, der har sider/funktionalitet, der er så langsom.

Men ofte, for at vise én side, skal du udføre flere dusin forespørgsler til databasen. Og hvis de udføres sekventielt, så har du ikke længere en anden grænse, men lad os sige 100ms pr. anmodning.

Her er de 5 bedste måder, hvorpå programmører fremskynder databaseforespørgsler:

1. Tilføjelse af indekser til tabeller i databasen.
2. Omskrivning og optimering af forespørgsler.
3. Aktiver (og konfigurer) caching på databasesiden.
4. Aktiver caching på klientsiden.
5. Udfører databasedenormalisering.

Du er allerede for det meste bekendt med alle disse ting, så det følgende vil kun være praktiske råd.

6.2 Indeks

Det er ingen hemmelighed, at arbejdet med en database fylder det meste af arbejdet på næsten ethvert websted. Og det er at arbejde med databasen, der oftest er flaskehalsen for webapplikationer.

I denne artikel vil jeg gerne give praktiske råd om brug af MySQL.

Jeg vil sige med det samme:

• denne artikel er skrevet om MySQL, selvom de generelle ting sandsynligvis vil være sande for enhver DBMS.
• alt skrevet i artiklen er mit personlige synspunkt og er ikke den ultimative sandhed.
• rådgivning foregiver ikke at være ny og er resultatet af en generalisering af den læste litteratur og personlige erfaringer.
• inden for rammerne af denne artikel vil jeg ikke komme ind på MySQL-konfigurationsproblemer.

Problemer ved brug af MySQL kan opdeles i følgende tre grupper (i rækkefølge efter vigtighed):

1. Ikke-brug eller misbrug af indekser.
2. Forkert databasestruktur.
3. Forkerte \ suboptimale SQL-forespørgsler.

Lad os se nærmere på hver af disse grupper.

Brug af indekser

Ikke at bruge eller misbruge indekser er det, der oftest bremser forespørgsler. For dem, der ikke er bekendt med mekanismen for, hvordan indekser fungerer eller endnu ikke har læst om det i manualen, anbefaler jeg dig kraftigt at læse den.

Tips til brug af indekser:

• Du behøver ikke at indeksere alt . Ganske ofte, uden at forstå betydningen, indekserer folk simpelthen alle felterne i en tabel. Indekser fremskynder hentning, men sænker rækkeindsættelser og opdateringer, så valget af hvert indeks skal være meningsfuldt.
• En af hovedparametrene, der kendetegner indekset, er selektivitet, som er antallet af forskellige elementer i indekset. Det giver ingen mening at indeksere et felt, der har to eller tre mulige værdier. Der vil kun være ringe gavn af et sådant indeks.
• Valget af indeks bør begynde med en analyse af alle forespørgsler mod en given tabel. Meget ofte, efter en sådan analyse, i stedet for tre eller fire indekser, kan du lave et sammensat et.
• Når du bruger sammensatte indekser, er rækkefølgen af ​​felterne i indekset kritisk.
• Glem ikke at dække indekser. Hvis alle data i en forespørgsel kan hentes fra et indeks, vil MySQL ikke få direkte adgang til tabellen. Sådanne anmodninger vil blive eksekveret meget hurtigt. For eksempel, for en forespørgsel SELECT name FROM user WHERE login='test'med et indeks (login, navn), er adgang til tabellen ikke påkrævet. Nogle gange giver det mening at tilføje et ekstra felt til et sammensat indeks, hvilket vil få indekset til at dække og fremskynde forespørgsler.
• For rækkeindekser er det ofte tilstrækkeligt kun at indeksere en del af rækken. Dette kan reducere indeksstørrelsen betydeligt.
• Hvis %det er i begyndelsen, LIKE(SELECT * FROM table WHERE field LIKE '%test')vil indekser ikke blive brugt.
• FULLTEXT- indekset bruges kun sammen med MATCH ... AGAINST- syntaksen .

6.3 Databasestruktur

En veldesignet database er nøglen til hurtigt og effektivt arbejde med databasen. På den anden side er en dårligt designet database altid en hovedpine for udviklere.

Tips til databasedesign:

1. Brug de mindst mulige datatyper. Jo større datatype, jo større tabel, jo flere diskadgange er nødvendige for at få dataene. Brug en meget bekvem procedure: SELECT * FROM table_name PROCEDURE ANALYSE();at bestemme de mindst mulige datatyper.
2. Overhold normale former under designfasen. Ofte tyr programmører til denormalisering allerede på dette stadium. Men i de fleste tilfælde er det i starten af ​​projektet langt fra indlysende, hvordan dette kan resultere. Denormalisering af en tabel er meget lettere end at lide af en suboptimalt denormaliseret en. Og JOINnogle gange virker det hurtigere end forkert denormaliserede tabeller.
3. Brug ikke NULLkolonner, medmindre du bevidst har brug for dem.

6.4 SQL-forespørgsler.

Lige så ofte er der et ønske om at omskrive alle forespørgsler i native SQL, så forespørgslen er så hurtig som muligt. Hvis du beslutter dig for at gøre dette, så er her nogle tips:

1. Undgå anmodninger i en løkke. SQL er et sprog af sæt, og skrivning af forespørgsler bør ikke behandles på funktionernes sprog, men på sproget af sæt.
2. Undgå *(stjerner) i forespørgsler. Skriv gerne præcis de felter, du vælger. Dette vil reducere mængden af ​​data, der hentes og sendes. Glem heller ikke at dække indekser. Selvom du vælger alle felterne i tabellen, er det bedre at angive dem. For det første forbedrer det kodens læsbarhed. Når du bruger stjerner, er det umuligt at finde ud af, hvilke felter der er i tabellen uden at kigge nærmere på det. For det andet har din tabel i dag fem INT- kolonner, og en måned senere blev endnu en TEXT og BLOB tilføjet , og stjernen forblev, som den var.
3. Når pagineret, for at få det samlede antal poster, brug SQL_CALC_FOUND_ROWSog SELECT FOUND_ROWS();Når brugt SQL_CALC_FOUND_ROWS MySQL, cacher det valgte antal rækker (før LIMIT anvendes), og når det bruges, SELECT FOUND_ROWS()returnerer kun denne cachelagrede værdi uden at skulle genudføre forespørgslen.
4. Glem ikke, at der INSERTer en syntaks for flere indsættelser. Én forespørgsel vil køre en størrelsesorden hurtigere end flere forespørgsler i en løkke.
5. Brug LIMIT, hvor du ikke har brug for alle data.
6. Brug INSERT… ON DUPLICATE KEY UPDATE…i stedet for og INSERTeller UPDATEefter valg, og ofte i stedet for REPLACE.
7. Glem ikke denne fantastiske funktion GROUP_CONCAT. Det kan hjælpe med komplekse forespørgsler.