Per scrivere applicazioni performanti non è solo necessario scrivere del buon codice, ma è necessario prestare molta attenzione a come si lavora con le proprie banche dati.

Per fare un count delle righe presenti in una tabella, il 90% dei programmatori utilizza:

SELECT COUNT(*) from tabella

Potrebbe sembrare corretto, ma non è proprio così.
Quando si esegue questa query, il client invia al server una richiesta di piccolissime dimensioni. Il server riceve la richiesta ed effettua uno scan totale della tabella per determinare il totale delle righe in essa presenti. Per ogni riga viene effettuato un semplice calcolo basato su una addizione.. qualcosa di paragonabile ad un foreach. Questa operazione può richiedere molto tempo su tabelle di grandi dimensioni.

Fortunatamente esiste una via alternativa per recuperare il conteggio totale delle righe di una determinata tabella.

Possiamo utilizzare la tabella sysindexes. Questa tabella, che v'invito ad analizzare, è composta da diverse colonne, una di queste è rows.

Questo campo contiene il numero totale di righe presenti all'interno di tutte le tabelle presenti nel database. Possiamo quindi optare per una query del tipo

SELECT rows FROM sysindexes WHERE id = OBJECT_ID(nostratabella') AND indid < 2

Il risultato sarà esattamente lo stesso ma il tempo di esecuzione sarà decisamente minore rispetto ad un full scan.

Allo stesso tempo evitiamo di utilizzare massivamente la clausola HAVING in sequenza a GROUP BY. Quando si effettua questo tipo di query, il group by divide le righe in set di rows gruppate ed aggregate per i loro valori, a questo punto la clausola HAVING elimina le righe indesiderate dai vari gruppi formati precedentemente. In molti casi, si può scrivere codice TSQL che esegue la stessa operazione senza utilizzare HAVING. Avere questo tipo di accorgimento può migliorare le performance delle query del circa 40%.

E' bene anche ricordarsi di cercare di utilizzare il più possibile stored procedures e viste invece di query di grandi dimensioni. Si riduce notevolmente il traffico di rete, questo perchè il client invia al server solamente il nome della stored o della vista (con alcuni paremetri) invece di una query di grandi dimensioni. Utilizzare le stored procedures e le viste può migliorare anche l'ambiente sicurezza.. è di fatto possibile assegnare ad un utenze particolari il permesso di accesso unicamente alle viste e non alle tabelle.