La pratica migliore per assicurare che tutti i tuoi requisiti siano soddisfatti è rispondere a 5 serie di domande – Chi? Perché? Cosa? Quando? Dove?

Il database di produzione gioca un ruolo cruciale. Tassare il database con requisiti ambigui è troppo rischioso. Quindi, prima di eseguire una query, assicurarsi che tutti i requisiti siano specifici e discussi con le parti interessate

Master the art of creating indexes properly

Il tuning delle prestazioni in SQL può essere fatto indicizzando correttamente, il che si traduce in un accesso più rapido al database nei momenti critici. Questa è un’area in cui la maggior parte dei novizi dei database fallisce. O cercano di indicizzare tutto o non indicizzare nulla, e nessuno di questi approcci funziona a loro favore.

Questo perché quando non si fa alcuna indicizzazione, le query saranno lente e metteranno un carico inutile sul database. D’altra parte, se indicizzate tutto, i vostri trigger di inserimento non funzioneranno come previsto, rendendo così il vostro database inefficiente. La chiave qui è trovare il giusto equilibrio.

Evitare di usare SELECT*

SELECT* (letto come select all) è spesso usato come abbreviazione per interrogare tutti i dati di una tabella. Anche se questo metodo funziona bene per le tabelle più piccole, appesantisce inutilmente le risorse del database quando una query viene eseguita su una tabella con molti campi e righe.

Il modo migliore è definire i campi nell’istruzione SELECT per istruire il database a interrogare solo i dati richiesti per soddisfare gli obiettivi finali.

Comprendiamo meglio con l’aiuto di un esempio:

Qui c’è un modo inefficiente perché questa query recupererà tutti i dati memorizzati nella tabella Utenti indipendentemente dalle vostre esigenze.

SELECT*

FROM Users

Questo è il modo più efficiente di interrogare in quanto preleva solo le informazioni necessarie ed evita di appesantire il database.

SELECT LastName, Address, Contact

FROM Users

Usa saggiamente le tabelle temporanee

Anche se le tabelle temporanee sono ottime da usare, aumentano esponenzialmente la complessità di una query. Si raccomanda vivamente di evitare l’uso di tabelle temporanee se il codice può essere scritto semplicemente.

Tuttavia, se avete bisogno di trattare una stored procedure che non può essere gestita con una singola query, l’uso di tabelle temporanee come intermediari può mettere fine alle vostre pene.

Evitare di usare COUNT()

Uno dei modi comuni attraverso cui gli sviluppatori controllano se un certo record esiste è usando COUNT() invece di EXISTS(). COUNT() è inefficiente perché scansiona l’intera tabella e conta tutte le query che soddisfano la condizione. D’altra parte, EXISTS() è più efficiente perché esce dal ciclo non appena trova il risultato desiderato. Questo contribuisce ad un migliore funzionamento e rende il codice più ordinato.

Evitare l’uso di caratteri jolly all’inizio del pattern LIKE

Per mettere a punto le vostre query SQL, dovete evitare di usare il pattern LIKE nel modo seguente:

SELECT* FROM Customers WHERE address LIKE ‘%bar%’;

Qui, il database non sarà in grado di utilizzare un indice adatto se esiste a causa del % di carattere jolly. Il sistema inizia eseguendo una scansione completa della tabella e questo richiede un pedaggio sulla sua velocità. Quindi, il modo migliore per scrivere questa query è:

SELECT* FROM Customers WHERE address LIKE ‘bar%’;

Evitare di usare SELECT DISTINCT

Anche se è possibile eliminare facilmente i duplicati da una query usando SELECT DISTINCT, questa funzione consuma una quantità apprezzabile di potenza di elaborazione. Inoltre, questa query funziona raggruppando tutti i campi nella query per presentare risultati distinti. Questo, a sua volta, la rende altamente imprecisa.

Il modo migliore per evitare qualsiasi record duplicato nella vostra query è aggiungere più campi. In questo modo, non ci sarà bisogno di raggruppare e i record recuperati saranno accurati.

Per esempio, ecco un modo inefficiente di farlo:

SELECT DISTINCT FirstName, LastName, State

FROM Users

Ecco il modo efficiente di farlo:

SELECT FirstName, LastName, Contact, Address, State, Zip

FROM Users

Dritta bonus: Tenere alcune query per le ore non di punta

Per garantire che il vostro database di produzione rimanga sicuro e sano, è altamente raccomandato di programmare alcune query per le ore non di punta, idealmente quando il numero di utenti concorrenti è più basso. Così, il centro della notte, 3-5 a.m. è il momento migliore per eseguire query come:

• Eseguire istruzioni in loop
• Eseguire SELECT* su grandi tabelle con oltre 1 milione di record
• Sottoquery annidate
• Ricerche con caratteri jolly
• CROSS JOINs
• SELECT DISTINCT statements

The Wrap Up

Il tuning delle prestazioni in SQL è importante per mantenere il vostro database sano, ma non è il compito più facile da realizzare. La performance delle vostre query SQL dipende da una serie di fattori come il vostro modello di database, il tipo di informazioni che dovete recuperare e così via.

Si raccomanda vivamente di evitare qualsiasi situazione imbarazzante tenendo una traccia di tutte le query che stanno per essere sparate, e fornendo le migliori soluzioni. Come DBA, potreste anche dotare gli sviluppatori di una dashboard guidata dai dati in modo che non debbano sparare query di tanto in tanto per recuperare le informazioni essenziali. Qui c’è un articolo incredibile su come si può creare un cruscotto SQL che estrae i dati direttamente dal database.

Quali sono le vostre opinioni su questo? Come mettete a punto le vostre query SQL? Fateci sapere.