PostgreSQL - Forespørgselsoptimering

Når vi laver multipler forespørgsler I et komplekst system tager vi mange gange ikke den rigtige vej for at få optimal ydeevne på databaseniveau, med nuværende teknologiske fremskridt og den computerkraft, som vi ofte ser på vores servere, kan vi tro, at databaseoptimering er et spørgsmål om fortid.
Dette kunne ikke være længere fra sandheden, på trods af udstyrets fremskridt er databaserne grundlæggende for applikationernes ydeevne, derfor kan en velskrevet og stærkt optimeret forespørgsel betyde flere sekunders belastning, som den sparer i systemet, hvis vi gange dette med antallet af samtidige brugere, ser vi, hvordan omkostningerne og strømmen blev spildt.
Optimer forespørgsler
Den bedste måde at forbedre effektiviteten af ​​vores databaser på er at starte med velskrevne forespørgsler, mange gange finder vi ud af, at forespørgslerne ikke er velskrevne, da de ikke er så optimerede som de burde være, der er mange årsager til dette, en af ​​dem er genbrug uden kodebevidsthed; Med dette mener vi, at hvis vi på et tidspunkt lavede en forespørgsel, der fungerer for os med en venstre deltage Vi vil fortsat anvende det, når vi øger antallet af tabeller, der skal konsulteres, når vi ændrer det og ændrer nogle klausuler med indre sammenføjning Det kan forkorte stien og spare processorforbrug.
SQL er et sprog, som selvom det er ret let at læse, men det har mange aspekter og mange variationer, der giver os mulighed for at gøre noget, der fungerer bedst og værst, er det op til os at vide, hvordan vi kan identificere, om vores løsning tilhører en kategori eller andet.
For at vide, at vi er på rette vej, er en af ​​de vigtigste ting at blive opdateret, det vil sige, at vi ikke kan fortsætte med at kode i SQL inden for PostgreSQL som om det var den første version, når vi er i version 9.
Om brug af underforespørgsler
Dette er en af ​​de mest almindelige fejl, vi laver, og det er, at vi tænker på en forespørgsel som et sæt stykker, som vi hænger sammen, indtil vi opnår et endeligt resultat, men denne adfærd har stor indflydelse på vores databases ydeevne.
Lad os se et eksempel på denne typiske adfærd:

 SELECT tract_id, (SELECT COUNT (*) FRA census.facts As F WHERE F.tract_id = T.tract_id) As num_facts, (SELECT COUNT (*) FRA census.lu_fact_types As Y WHERE Y.fact_type_id IN (SELECT fact_type_id FROM. fakta F HVOR F.tract_id = T.tract_id)) As num_fact_types FROM census.lu_tracts As T; 

Nu, hvis vi ser grafen for FORKLARE Fra denne forespørgsel vil vi indse, hvor dyrt det er at gøre det på denne måde:

FORSTØRRE

Som vi kan se, har vi flere punkter, der er flaskehalse i denne forespørgsel, bortset fra alle de data, der skal flyttes ineffektivt, til dette vil vi omskrive det på en mere optimal måde og sammenligne det med en ny graf over FORKLARE.

 VÆLG T.tract_id, COUNT (f.fact_type_id) As num_facts, COUNT (DISTINCT fact_type_id) As num_fact_types FROM census.lu_tracts As T LEFT JOIN census.facts As F ON T.tract_id = F.tract_id GROUP BY T.tract_; 

I denne nye version af vores forespørgsel undgår vi at bruge underforespørgsler, i stedet gør vi et tilsvarende med venstre deltage Y gruppe efterHvis vi ser grafen, kan vi se forskellen.

FORSTØRRE

Vi kan se, hvordan måden at opnå vores resultat har været meget kortere, hvilket giver os en højere ydeevne, med dette betyder vi ikke, at vi må ekskludere underspørgsmålene i vores arbejdsværktøjer, men snarere at vi skal være klar over, at de kan findes bedre veje til det, vi måske foreslår i øjeblikket.Kan du lide og hjælpe denne vejledning?Du kan belønne forfatteren ved at trykke på denne knap for at give ham et positivt punkt