Home Big Data Soluzioni Come ottimizzare le query SQL: gli aspetti meno ovvi

Come ottimizzare le query SQL: gli aspetti meno ovvi

Abbiamo già considerato l’ottimizzazione delle query SQL e in generale di un ambiente database SQL dal punto di vista di alcuni approcci di alto livello, qui invece vogliamo concentrarci su alcuni aspetti più tecnici la cui adozione è meno scontata di altri.

Si tratta di elementi che possono da un lato semplificare il lavoro dello sviluppatore SQL ma dall’altro impattare negativamente sulle prestazioni delle operazioni di interrogazione e modifica delle tabelle.

Una prima considerazione riguarda i cursori, che sono sempre un argomento piuttosto spinoso. La nostra opinione è che in generale vadano evitati se si punta ad avere prestazioni elevate nelle query SQL, anche perché il loro funzionamento può bloccare altre operazioni.

Quando l’uso dei cursori è opportuno o inevitabile, meglio non farli operare su tabelle di produzione ma su tabelle temporanee, sempre per evitare problemi nelle operazioni concorrenti su medesime tabelle.

Le tabelle temporanee sono in generale una buona opzione quando c’è il rischio che alcune operazioni su grandi tabelle richiedano troppe risorse. In questi casi, se possibile, è meglio estrarre preventivamente dalle grandi tabelle il sottoinsieme di dati che ci interessa e creare così una tabella temporanea più “agile”. Aumentare il numero di tabelle temporanee può quindi avere effetti positivi.

Lo stesso non si può dire delle viste. Come principio le viste sono un buon sistema per generare tabelle (virtuali) che contengono solo i dati destinati a gruppi di utenti, e oscurano gli altri per la privacy. Attenzione però a non farsi prendere la mano con le viste nidificate: troppi livelli di viste rallentano il database.

Per ragioni simili va esercitata cautela anche nella gestione dei trigger e, nei casi specifici, degli ORM (Object-Relational Mapper). I primi generano comunque un maggior carico di lavoro per il server e questo limite è noto.

Più pericoloso è il fatto che un trigger (o peggio una sequenza di trigger) può bloccare più tabelle all’interno di una stessa transazione, sino a quando non si completa. I limiti prestazionali sono anche il punto debole degli ORM, dato che portano a generare codice tutt’altro che ottimizzato.

Ci sono poi numerosi accorgimenti di dettaglio che possono aumentare sensibilmente la velocità delle operazioni su un database SQL.

Ad esempio usare operazioni di CASE invece che di UPDATE per evitare il ritardo della registrazione nei log, non scandire tutta una tabella (tipicamente alla ricerca della presenza di un particolare valore) se una query può “uscirne” prima, non selezionare tutte le colonne di una riga se ne servono di meno.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome

Se questo articolo ti è piaciuto e vuoi rimanere sempre informato sulle novità tecnologiche
css.php