🟡 Oltre la query: capire le prestazioni in SQL Server

🔵 Introduzione

Ogni tanto mi prende la voglia di capire davvero quanto conosco di SQL Server. Non basta più scrivere una query e dire “mi sembra funzioni”, o pensare che la forma sia elegante. Il mondo informatico sembra infinito, e la mia conoscenza di un DBMS come SQL Server a volte mi sembra minuscola.

Così ho deciso di partire dai concetti base legati alle prestazioni delle query, quelli che permettono di andare oltre la superficie e iniziare a “misurare” prima di ottimizzare.

La scoperta di questa modalità di studio mi ha portato anche a voler divulgare ciò che imparo, perché solo sapendo spiegare un concetto posso dire di averlo davvero compreso.

🟣 Il primo passo: STATISTICS IO e TIME

Non sapevo da dove cominciare. Navigando tra risorse online ho capito che uno dei primi passi concreti era abilitare le statistiche in SSMS:

SET STATISTICS IO, TIME ON;

Aprire la finestra Messages e vedere numeri e valori apparentemente freddi può sembrare “lezioso”, ma è proprio lì che si nascondono le informazioni più utili: scan count, logical reads, physical reads, tempi CPU e totali.

All’inizio non bastava avere i numeri davanti: dovevo capire cosa significassero realmente, come si relazionavano alle tabelle, agli indici, e soprattutto alle query che scrivevo.

Ad esempio, attivando le statistiche, SSMS restituisce valori come:

·        Scan count: quante volte SQL Server ha letto l’oggetto (tabella o indice)

·        Logical reads: quante pagine da 8 KB sono state lette in memoria

·        Physical reads: quante pagine sono state lette dal disco

A prima vista sembrano solo numeri, ma imparare a leggerli permette di capire se una query sta leggendo troppo o se l’indice è sfruttato correttamente.

🔴 Creare esercizi e sperimentare

Per interiorizzare questi concetti ho creato esercizi semplici, partendo da una tabella Ordini e aggiungendo poi la tabella Clienti per “complicare” con una join.

La mia prima azione concreta è stata: aggiungere un indice mirato e osservare come cambiavano scan count, logical reads e tempi.

Ho scoperto che un indice non è solo un indice fine a se stesso: può essere creato in modi diversi e incorpora dettagli importanti come le colonne INCLUDE, che evitano i Key Lookup e trasformano un indice in un “covering index”.

Una cosa che davo per scontata, ora l’ho metabolizzata davvero.

⚪ Verso un percorso di studio personale

Questa esperienza mi ha spinto a voler costruire un percorso per approfondire tutto ciò che può dare uno slancio ulteriore alla mia conoscenza di SQL Server.

Ho creato un repository dedicato su GitHub → sqlserver-lab dove pubblico il materiale dello studio, pronto per essere consultato o usato da chiunque voglia approfondire.

La soddisfazione più grande? Sapere di poter spiegare ciò che ora conosco. Tutti quei numeri, statistiche e indici non sono più astratti: sono diventati miei, e posso raccontarli.

✨ Conclusione

Studiare le prestazioni delle query, leggere le statistiche IO e TIME, capire gli indici e sperimentare non è solo utile: è una porta verso conoscenze più ampie. A volte può sembrare poco utile ma, nel medio termine ripaga e apre a nuove possibilità.

E questo è il bello dell’informatica: più scopri, più capisci quanto c’è ancora da esplorare.