PostgreSQL - Optimizarea interogărilor

Când facem multipli întrebări Într-un sistem complex de multe ori nu luăm calea adecvată pentru a avea performanțe optime la nivelul bazei de date, cu avansul tehnologic actual și puterea de calcul pe care o vedem adesea în serverele noastre, putem crede că optimizarea bazei de date este o chestiune din trecut.
Acest lucru nu poate fi mai departe de adevăr, în ciuda avansului în putere al echipamentelor, bazele de date sunt fundamentale pentru performanța aplicațiilor, din acest motiv o interogare bine scrisă și foarte optimizată poate însemna câteva secunde de încărcare pe care o salvează în sistemul, dacă înmulțim acest lucru cu numărul de utilizatori concurenți, vedem cum se risipeau costurile și puterea.
Optimizați interogările
Cel mai bun mod de a îmbunătăți performanța bazelor noastre de date este să începem cu interogări bine scrise, de multe ori constatăm că interogările nu sunt bine scrise, deoarece nu sunt atât de optimizate cum ar trebui, există multe cauze pentru aceasta, una dintre ele este refolosirea fără conștientizarea codului; Prin aceasta înțelegem că, dacă la un moment dat am făcut o interogare care funcționează pentru noi cu un stânga se alătură Vom continua să-l aplicăm la creșterea numărului de tabele care urmează să fie consultate, atunci când îl modificăm și schimbăm unele clauze cu îmbinare interioară Ar putea scurta calea și economisi consumul procesorului.
SQL este un limbaj care, deși este destul de ușor de citit, are multe aspecte și multe variații care ne permit să facem ceva care funcționează în cel mai bun și mai rău mod, depinde de noi să știm cum să identificăm dacă soluția noastră aparține o categorie sau alta.
Pentru a ști că suntem pe drumul cel bun, unul dintre cele mai importante lucruri este să fie actualizat, adică nu putem continua codarea în SQL în PostgreSQL de parcă ar fi prima versiune când suntem în versiunea 9.
Despre utilizarea subinterogărilor
Aceasta este una dintre cele mai frecvente greșeli pe care le facem, și anume că ne gândim la o interogare ca la un set de piese pe care le îmbinăm până obținem un rezultat final, totuși acest comportament are un impact mare asupra performanței bazei noastre de date.
Să vedem un exemplu al acestui comportament tipic:

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

Acum, dacă vedem graficul EXPLICA Din această interogare vom realiza cât de scump este să o faci în acest fel:

MARI

După cum putem vedea, avem mai multe puncte care reprezintă blocaje în această interogare, în afară de toate datele care trebuie mutate ineficient, pentru aceasta o vom rescrie într-un mod mai optim și o vom compara cu un nou grafic al EXPLICA.

 SELECT 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_id; 

În această nouă versiune a interogării noastre, evităm utilizarea subinterogărilor, în schimb facem un echivalent cu stânga se alătură Da a se grupa cuDacă vedem graficul putem face diferența.

MARI

Putem vedea cum modul de obținere a rezultatului nostru a fost mult mai scurt, ceea ce ne oferă o performanță mai mare, cu aceasta nu vrem să excludem subinterogările instrumentelor noastre de lucru, ci mai degrabă că trebuie să fim conștienți de faptul că acestea pot există căi mai bune pentru ceea ce putem propune în acest moment.V-a plăcut și ați ajutat acest tutorial?Puteți recompensa autorul apăsând acest buton pentru a-i oferi un punct pozitiv