Optimalisering av datasamplingsfrekvens

6.1 Introduksjon

La oss nå gå fra teori til praksis.

Vi lever i den virkelige verden og alle programvareprodukter er til syvende og sist laget for levende mennesker. Og disse levende menneskene er veldig irriterte over nettsteder som laster sakte, og programmer som bremser ned.

Og hvis en databasespørring tar mer enn et sekund, er dette uakseptabelt . Brukere vil rett og slett ikke bruke et produkt som har sider/funksjonalitet som er så treg.

Men ofte, for å vise én side, må du utføre flere dusin spørringer til databasen. Og hvis de utføres sekvensielt, har du ikke lenger en andre grense, men la oss si 100 ms per forespørsel.

Her er de 5 beste måtene programmerere fremskynder databasespørsmål på:

1. Legge til indekser til tabeller i databasen.
2. Omskriving og optimalisering av spørringer.
3. Aktiver (og konfigurer) caching på databasesiden.
4. Aktiver caching på klientsiden.
5. Utfører databasedenormalisering.

Du er allerede kjent med alle disse tingene for det meste, så følgende vil bare være praktiske råd.

6.2 Indekser

Det er ingen hemmelighet at arbeid med en database tar opp det meste av arbeidet på nesten alle nettsteder. Og det er å jobbe med databasen som oftest er flaskehalsen til webapplikasjoner.

I denne artikkelen vil jeg gi praktiske råd om bruk av MySQL.

Jeg vil si med en gang:

• denne artikkelen er skrevet om MySQL, selv om de generelle tingene sannsynligvis vil være sanne for alle DBMS.
• alt som er skrevet i artikkelen er mitt personlige synspunkt, og er ikke den ultimate sannheten.
• råd utgir seg ikke for å være nye og er et resultat av en generalisering av leselitteraturen og personlig erfaring.
• innenfor rammen av denne artikkelen vil jeg ikke berøre MySQL-konfigurasjonsproblemer.

Problemer ved bruk av MySQL kan deles inn i følgende tre grupper (i viktig rekkefølge):

1. Ikke-bruk eller misbruk av indekser.
2. Feil databasestruktur.
3. Feil \ suboptimal SQL-spørring.

La oss se nærmere på hver av disse gruppene.

Bruke indekser

Å ikke bruke eller misbruke indekser er det som oftest bremser søkene. For de som ikke er kjent med mekanismen for hvordan indekser fungerer eller ennå ikke har lest om det i manualen, anbefaler jeg deg sterkt å lese den.

Tips for bruk av indekser:

• Du trenger ikke å indeksere alt . Ganske ofte, uten å forstå betydningen, indekserer folk ganske enkelt alle feltene i en tabell. Indekser øker hentingene, men senker radinnsettinger og oppdateringer, så valget av hver indeks må være meningsfullt.
• En av hovedparametrene som kjennetegner indeksen er selektivitet, som er antall ulike elementer i indeksen. Det gir ingen mening å indeksere et felt som har to eller tre mulige verdier. Det vil være liten nytte av en slik indeks.
• Valget av indekser bør begynne med en analyse av alle spørringer mot en gitt tabell. Svært ofte, etter en slik analyse, i stedet for tre eller fire indekser, kan du lage en sammensatt.
• Ved bruk av sammensatte indekser er rekkefølgen på feltene i indeksen kritisk.
• Ikke glem å dekke indekser. Hvis alle data i en spørring kan hentes fra en indeks, vil ikke MySQL få direkte tilgang til tabellen. Slike forespørsler vil bli utført veldig raskt. For eksempel, for en spørring SELECT name FROM user WHERE login='test'med en indeks (pålogging, navn), er det ikke nødvendig med tilgang til tabellen. Noen ganger er det fornuftig å legge til et ekstra felt i en sammensatt indeks, som vil gjøre indeksen dekker og øke hastigheten på spørringene.
• For radindekser er det ofte tilstrekkelig å indeksere bare en del av raden. Dette kan redusere indeksstørrelsen betydelig.
• Hvis %det er i begynnelsen, LIKE(SELECT * FROM table WHERE field LIKE '%test')vil ikke indekser bli brukt.
• FULLTEXT - indeksen brukes bare med MATCH ... MOT - syntaksen .

6.3 Databasestruktur

En godt utformet database er nøkkelen til raskt og effektivt arbeid med databasen. På den annen side er en dårlig designet database alltid en hodepine for utviklere.

Tips for databasedesign:

1. Bruk de minste mulige datatypene. Jo større datatype, jo større tabell, jo flere disktilganger er nødvendig for å få dataene. Bruk en veldig praktisk prosedyre: SELECT * FROM table_name PROCEDURE ANALYSE();for å bestemme minimum mulige datatyper.
2. Observer normale former under prosjekteringsfasen. Ofte tyr programmerere til denormalisering allerede på dette stadiet. Men i de fleste tilfeller, i starten av prosjektet, er det langt fra åpenbart hvordan dette kan resultere. Å denormalisere en tabell er mye lettere enn å lide av en suboptimalt denormalisert en. Og JOINnoen ganger fungerer det raskere enn feil denormaliserte tabeller.
3. Ikke bruk NULLkolonner med mindre du bevisst trenger dem.

6.4 SQL-spørringer.

Like ofte er det et ønske om å omskrive alle spørringer i native SQL slik at spørringen er så rask som mulig. Hvis du bestemmer deg for å gjøre dette, så her er noen tips:

1. Unngå forespørsler i en løkke. SQL er et setts språk, og skriving av spørringer bør ikke tilnærmes på funksjonsspråket, men på settspråket.
2. Unngå *(stjerner) i spørringer. Skriv gjerne opp akkurat de feltene du velger. Dette vil redusere mengden data som hentes og sendes. Ikke glem å dekke indekser. Selv om du velger alle feltene i tabellen, er det bedre å liste dem opp. For det første forbedrer det lesbarheten til koden. Når du bruker asterisker, er det umulig å finne ut hvilke felt som er i tabellen uten å se nærmere på det. For det andre , i dag har tabellen din fem INT- kolonner, og en måned senere ble det lagt til en TEXT og BLOB til , og stjernen forble som den var.
3. Når paginert, for å få det totale antallet poster, bruk SQL_CALC_FOUND_ROWSog SELECT FOUND_ROWS();When used SQL_CALC_FOUND_ROWS MySQL, cacher det valgte antallet rader (før LIMIT brukes), og når det brukes, SELECT FOUND_ROWS()returnerer kun denne bufrede verdien uten å måtte utføre spørringen på nytt.
4. Ikke glem at det INSERTer en syntaks for flere innlegg. Én spørring vil kjøre en størrelsesorden raskere enn flere spørringer i en løkke.
5. Bruk LIMITder du ikke trenger all data.
6. Bruk INSERT… ON DUPLICATE KEY UPDATE…i stedet for og INSERTeller UPDATEetter valg, og ofte i stedet for REPLACE.
7. Ikke glem denne fantastiske funksjonen GROUP_CONCAT. Det kan hjelpe med komplekse spørsmål.