È facile iniziare ad armeggiare con gli ingranaggi dell'ottimizzazione delle query SQL. Apri SQL Server Management Studio (SSMS), monitori il tempo di attesa, rivedi il piano di esecuzione, raccogli le informazioni sugli oggetti e inizi a ottimizzare SQL finché non esegui una macchina ottimizzata.
Se sei abbastanza bravo, ottieni una rapida vittoria e torni al caos regolarmente programmato. Ma se aggiusti la cosa sbagliata, o aggiusti la cosa giusta nella direzione sbagliata, beh, ecco il tuo mercoledì.
Ottimizzazione delle query SQL? Cosa ti fa pensare di averne bisogno?
Il più delle volte, si tratta di un picco di ticket per problemi o reclami degli utenti. "Perché il sistema è così lento?" i tuoi utenti si lamentano. "Ci vuole un'eternità per eseguire i nostri soliti rapporti questa settimana."
Questa è una descrizione piuttosto vaga, ovviamente. Sarebbe bello se potessero dirti:"Le cose sono lente perché hai una conversione implicita nella riga 62 di CurrentOrderQuery5.sql. La colonna è varchar e stai passando un intero. Ma non è probabile che i tuoi utenti possano vedere quel livello di dettaglio.
Almeno i ticket di emergenza e le telefonate costituiscono una metrica attiva:facile da individuare, facile da misurare. Quando iniziano ad arrivare, puoi essere ragionevolmente sicuro che è il momento dell'ottimizzazione di SQL.
Ma ci sono altre metriche passive che rendono meno chiara la necessità. Cose come il calo delle vendite, che potrebbe essere dovuto a un numero qualsiasi di fattori. È perché le query dolorosamente lente nel tuo negozio online stanno costringendo i tuoi clienti ad abbandonare i loro carrelli della spesa? È perché l'economia è in cattive condizioni?
Oppure potrebbero essere cose come prestazioni lente di SQL Server. È perché una query scritta male sta inviando letture logiche alle stelle? È perché il server ha poche risorse fisiche come memoria e spazio di archiviazione?
In entrambi gli scenari, l'ottimizzazione delle query SQL può essere utile con la prima opzione, ma non con la seconda.
Perché applicare la soluzione giusta al problema sbagliato?
Prima di intraprendere il percorso di ottimizzazione, assicurati che l'ottimizzazione sia la soluzione giusta al problema giusto.
L'ottimizzazione di SQL è un processo tecnico, ma ogni passaggio tecnico ha le sue radici nel buon senso degli affari. Potresti passare giorni cercando di ridurre il tempo di esecuzione di pochi millisecondi o di ridurre il numero di letture logiche del cinque percento, ma la riduzione vale il tuo tempo? È vero che è importante soddisfare le esigenze degli utenti, ma ogni sforzo alla fine arriva al punto di diminuire i rendimenti.
Considera questi problemi di prestazioni delle query SQL e il contesto aziendale che li circonda:
- Rendimento accettabile — L'esecuzione di una query richiede 10 minuti e l'utente desidera che venga eseguita in un minuto; sembra una ragionevole disparità e un obiettivo raggiungibile per l'ottimizzazione. Tuttavia, se la query richiede una notte e l'utente ritiene che dovrebbe essere eseguita in un minuto, potrebbe trattarsi di qualcosa di più di un problema di ottimizzazione. Per prima cosa, potresti dover istruire l'utente sulla quantità di lavoro che la query sta effettivamente eseguendo. Dall'altro, potrebbe essere un problema con il modo in cui è stato progettato il database o il modo in cui è stata scritta l'applicazione client.
- Utilità — Supponiamo che tu sia responsabile dell'amministrazione del database finanziario in un'azienda manifatturiera. Alla fine di ogni mese, gli utenti si lamentano di scarse prestazioni. Traccia il problema da una serie di rapporti di fine mese gestiti dalla contabilità che richiedono ore ciascuno e vanno direttamente in uno schedario non esaminato da nessuno. Invece di eseguire l'ottimizzazione, spieghi il problema ai responsabili aziendali e ottieni l'autorizzazione per eliminare i rapporti.
- Spostamento temporale — Oppure, supponiamo che le stesse relazioni siano importanti per la governance ma non urgenti per l'azienda. Se vengono eseguiti una volta alla settimana o al mese, possono essere programmati per le ore non di punta memorizzando nella cache il set di dati e inviando i risultati a un file. Ciò elimina il collo di bottiglia sugli altri utenti aziendali e libera l'utente Contabilità dal dover attendere i rapporti.
Quando consideri il contesto aziendale nella tua decisione di ottimizzazione, puoi stabilire delle priorità e guadagnare tempo.
Quando ottimizzi le query SQL, prova a creare diagrammi SQL
SSMS e gli strumenti integrati in SQL Server offrono la maggior parte di ciò di cui hai bisogno per un'efficace ottimizzazione delle query SQL. Combina gli strumenti con un approccio metodico attorno ai seguenti passaggi, come descritto nell'e-book "La guida fondamentale all'ottimizzazione delle query SQL":
- Monitoraggio del tempo di attesa
- Esamina il piano di esecuzione
- Raccogli informazioni sugli oggetti
- Trova la tabella di marcia
- Identifica gli inibitori delle prestazioni
Nel passaggio 4, l'obiettivo è guidare la query con la tabella che restituisce il minor numero di dati. Quando si studiano join e predicati e si filtrano prima nella query anziché in seguito, si riduce il numero di letture logiche. Questo è un grande passo avanti nell'ottimizzazione delle query SQL.
Il diagramma SQL è una tecnica grafica per mappare la quantità di dati nelle tabelle e trovare quale filtro restituirà il minor numero di record. Innanzitutto, si determina quali tabelle contengono le informazioni dettagliate e quali tabelle sono le tabelle principali o di ricerca. Considera il semplice esempio di questa query su un database di registrazione universitaria:
La tabella dei dettagli è la registrazione. Ha due tabelle di ricerca, studente e classe. Per rappresentare graficamente queste tabelle, disegna un albero capovolto collegando la tabella dei dettagli (in alto) con le frecce (o i collegamenti) alle tabelle di ricerca, in questo modo:
Ora, calcola il numero relativo di record richiesti per i criteri di unione (ovvero il rapporto medio di righe correlate tra la tabella dei dettagli e le tabelle di ricerca). Scrivi i numeri a ciascuna estremità della freccia. In questo esempio, per ogni studente ci sono circa 5 record nella tabella di registrazione e per ogni classe ci sono circa 30 record in registrazione. Ciò significa che non dovrebbe mai essere necessario UNIRE più di 150 (5×30) record per ottenere un risultato per ogni singolo studente o ogni singola classe.
Questo esercizio è utile se le tue colonne di join non sono indicizzate o se non sei sicuro che siano indicizzate.
Quindi, guarda i predicati di filtraggio per trovare con quale tabella guidare la query. Questa query aveva due filtri:uno sulla registrazione annullata ='N' e l'altro su signup_date tra due date. Per vedere quanto è selettivo il filtro, esegui questa query al momento della registrazione:
seleziona conteggio(1) dalla registrazione dove annullato ='N'
E r.signup_date TRA :beg_date E :beg_date +1
Restituisce 4.344 record sui 79.800 record totali registrati. Cioè, il 5,43 percento dei record verrà letto con quel filtro.
L'altro filtro è sulla classe:
seleziona count(1) dalla classe dove name ='ENGLISH 101'
Restituisce due record su 1.000, o 0,2 percento, che rappresenta un filtro molto più selettivo. Pertanto, la classe è la tabella guida e quella su cui concentrare prima l'ottimizzazione di SQL.
La voce dell'utente
Se sei sicuro di aver bisogno dell'ottimizzazione SQL, "La guida fondamentale all'ottimizzazione delle query SQL" offre ulteriori informazioni. Ti guida attraverso cinque suggerimenti per l'ottimizzazione delle prestazioni con query di copia e incolla e case study, incluso quello descritto sopra.
Probabilmente scoprirai che il più importante strumento di ottimizzazione delle query SQL è la voce dell'utente. Come mai? Perché quella voce ti fa sapere quando iniziare a ottimizzare e ti dice quando hai ottimizzato abbastanza. Può assicurarti di iniziare ad armeggiare con gli ingranaggi quando è necessario e di fermarti mentre sei ancora in vantaggio.
