Quando si scrivono query o codice del database di SQL ServerSQL Server (procedure e visualizzazioni) si consiglia sempre di prendere nota del piano di esecuzione. Ci sono diverse ragioni per questo. In primo luogo, l'ottimizzatore potrebbe scegliere un piano che non ti aspetti. Ad esempio, eseguire la scansione dell'indice di una tabella di grandi dimensioni prima della corrispondenza con una tabella più piccola. In secondo luogo, è necessario prendere in considerazione il rendimento di questa query nei mesi o negli anni a venire se le query vengono eseguite in un nuovo sistema con piccole tabelle che aumenteranno. E infine, ma soprattutto, quanto è veloce questa query e quante risorse utilizza. L'ultimo punto potrebbe non sembrare così importante, potresti pensare che bastano meno di 3 secondi, ma se potesse funzionare in <1 secondo non sarebbe meglio? Se i tuoi database sono ospitati su cloud, anche la riduzione delle risorse potrebbe farti risparmiare denaro.
Molti casi di ottimizzazione SQL derivano normalmente da un problema rilevato dall'utente finale o dal software di monitoraggio. "Perché questo rapporto impiega 30 minuti per essere generato?", "Cosa sta causando quel picco nell'attesa di I/O" o "Perché questi lavori impiegano il doppio del tempo rispetto all'anno scorso?"
In tutti questi scenari si tratta comunque di una certa conoscenza dei piani di esecuzione e del modo migliore per correggere l'SQL per migliorare la situazione e questo può richiedere molto tempo e non sempre avere successo.
Facciamo un esempio. Quindi, stai scrivendo una nuova query, eseguendola e poi pensando, oh cielo, ci sta impiegando troppo tempo.
17 secondi per 730 righe, cosa devo fare?
Per prima cosa, esaminiamo il piano di esecuzione:
Questo non è sempre semplice se devi ingrandire e rimpicciolire per dargli un senso. Quindi, il primo consiglio è quello di procurarsi un buon visualizzatore di piani come questo con Spotlight Tuning Pack.
Il visualizzatore del piano evidenzia le informazioni chiave di cui abbiamo bisogno e dove si trovano le operazioni principali, oltre a evidenziare eventuali avvisi.
Ecco un esempio:
Quindi, c'è un problema con questo codice, ma cosa possiamo fare al riguardo?
Beh, in realtà parecchio. Potremmo usare suggerimenti per le query, esaminare l'aggiunta di alcuni indici (non dimenticare che ciò potrebbe influire su altre query e DML), aggiungendo bit di codice che non modificano il set di risultati ma influenzano l'ottimizzatore per generare un piano diverso e piccoli trucchi per fermare l'ottimizzatore considerando un particolare indice che sta utilizzando e magari generare un nuovo piano. Ma questo è tutto tentativi ed errori e richiede molto tempo per farlo manualmente.
Aggiungendo l'applicazione Spotlight Extensions a SSMS e sottoscrivendo Spotlight Tuning Pack, possiamo lasciare che la funzione di ottimizzazione del Tuning Pack faccia tutto il duro lavoro per noi.
Potresti aver notato nel primo screenshot che quando la funzione è abilitata, rileva automaticamente che l'ottimizzazione è possibile:
Fare clic su Visualizza analisi
È quindi possibile fare clic sul pulsante Ottimizza e il motore di ottimizzazione analizzerà il codice e inizierà ad applicare regole di riscrittura che cambieranno la sintassi dell'SQL fornendo alternative che forniscono lo stesso set di risultati, quindi le testeranno in modo da poter vedere se esiste un'esecuzione alternativa i piani sono più veloci e perché. Le regole vengono applicate in combinazioni, quindi le possibili alternative potrebbero essere più di 100. Tuttavia, lo strumento mostra solo alternative più veloci dell'originale.
Questo processo viene eseguito in background e ti fa risparmiare un'immensa quantità di tempo se hai tentato di farlo manualmente.
E quando vengono mostrati i risultati puoi confrontare le alternative, vedere le differenze di codice, confrontare i piani e rivedere le statistiche.
Quindi, torna a SSMS con la mia nuova versione della query e provala.
Successo.
Se si trova in un ambiente di sviluppo, potresti prendere in considerazione la possibilità di svuotare la cache del buffer utilizzando DBCC DROPCLEANBUFFERS, per testare le query con una cache del buffer a freddo senza spegnere e riavviare il server.
Inoltre, considera l'aggiunta di SET STATISTICS IO ON alla query per ulteriori informazioni sul motivo per cui la sintassi della query ha fatto la differenza:
Originale:
Riscrivi:
E questo può essere ottenuto anche nel Tuning Pack con la funzione di confronto delle statistiche:
Quindi, con il cambiamento riuscito e l'utente finale felice, passa alla query successiva. Migliorando continuamente le prestazioni delle singole query, miglioriamo le prestazioni dell'istanza.
