PostgreSQL - Ottimizzazione delle query

Quando facciamo multipli interrogazioni In un sistema complesso molte volte non prendiamo la strada appropriata per avere prestazioni ottimali a livello di database, con l'attuale progresso tecnologico e la potenza di calcolo che spesso vediamo nei nostri server possiamo pensare che l'ottimizzazione del database sia una questione del passato.
Ciò non potrebbe essere più lontano dalla verità, nonostante l'avanzamento in potenza delle apparecchiature, i database sono fondamentali per le prestazioni delle applicazioni, per questo motivo una query ben scritta e altamente ottimizzata può significare diversi secondi di carico che si salva in il sistema, se moltiplichiamo questo per il numero di utenti simultanei vediamo come il costo e la potenza venivano sprecati.
Ottimizza query
Il modo migliore per migliorare le prestazioni dei nostri database è iniziare con query ben scritte, molte volte troviamo che le query non sono ben scritte poiché non sono ottimizzate come dovrebbero essere, ci sono molte cause per questo, una di queste è il riutilizzo senza la consapevolezza del codice; Con questo intendiamo che se a un certo punto facessimo una query che funziona per noi con a join sinistro Continueremo ad applicarlo quando si aumenta il numero di tabelle da consultare, quando lo si modifica e si cambiano alcune clausole di unione interna Potrebbe accorciare il percorso e risparmiare il consumo del processore.
SQL è un linguaggio che sebbene sia abbastanza facile da leggere, ha molti aspetti e molte varianti che ci permettono di fare qualcosa che funzioni nel modo migliore e peggiore, sta a noi sapere come identificare se la nostra soluzione appartiene a una categoria o altro.
Per sapere che siamo sulla strada giusta una delle cose più importanti è essere aggiornati, cioè non possiamo continuare a codificare in SQL all'interno PostgreSQL come se fosse la prima versione quando siamo in versione 9.
Informazioni sull'utilizzo di sottoquery
Questo è uno degli errori più comuni che commettiamo, ed è che pensiamo a una query come a un insieme di pezzi che mescoliamo insieme fino ad ottenere un risultato finale, tuttavia questo comportamento ha un forte impatto sulle prestazioni del nostro database.
Vediamo un esempio di questo comportamento tipico:

 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. fatti F WHERE F.tract_id = T.tract_id)) As num_fact_types FROM census.lu_tracts As T; 

Ora, se vediamo il grafico di SPIEGARE Da questa query ci renderemo conto di quanto sia costoso farlo in questo modo:

INGRANDIRE

Come possiamo vedere, abbiamo diversi punti che sono colli di bottiglia in questa query, a parte tutti i dati che devono essere spostati in modo inefficiente, per questo lo riscriveremo in un modo più ottimale e lo confronteremo con un nuovo grafico del SPIEGARE.

 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 UNISCI census.facts As F ON T.tract_id = F.tract_id GRUPPO PER T.tract_id; 

In questa nuova versione della nostra query evitiamo di usare sottoquery, invece facciamo un equivalente con join sinistro sì raggruppa perSe vediamo il grafico possiamo dire la differenza.

INGRANDIRE

Si vede come la strada per ottenere il nostro risultato sia stata molto più breve il che ci dà una resa maggiore, con questo non intendiamo che dobbiamo escludere le sottoquery dei nostri strumenti di lavoro, ma piuttosto che dobbiamo essere consapevoli che possono esistono percorsi migliori per ciò che possiamo proporre in questo momento.Ti è piaciuto e hai aiutato questo Tutorial?Puoi premiare l'autore premendo questo pulsante per dargli un punto positivo