Tuttavia, quello che ho evidenziato nel mio giorno per giorno è che ancora molti sono gli sviluppatori che tanto preoccuparsi indici della tabella. Ciò che si nota, è che almeno in un primo momento, lo sviluppatore è più preoccupato di fare il suo lavoro di query e nella fornitura dei dati per l'utente.
Come risultato, nel medio termine, quello che hai è enorme dispendio di risorse del server e il ritardo così odiato nell'applicazione. E 'chiaro che esistono molti altri punti che riducono le prestazioni di un'applicazione, ad esempio: le statistiche di accesso dati obsoleti, blocca le connessioni' (il più delle volte, a causa della mancanza di indici), uso eccessivo di cursori, ecc
Ma si può essere certi: il cattivo uso di indici e anche la loro assenza è la principale causa dei problemi di prestazioni delle applicazioni SQL Server '. In questo articolo presenterò 10 suggerimenti importante che ogni sviluppatore deve sapere quando si lavora con SQL Server.
Suggerimenti su come analizzare il piano di esecuzione, i metodi per la sostituzione di cursori, l'uso di sub-query, l'uso di colonna indicizzata nella clausola WHERE, alla fine, suggerimenti che certamente vi aiuteranno a ottenere un maggiore beneficio da SQL Server.
Bene, data questa piccola introduzione, passiamo a ciò che conta.
1. Ho sempre analizzare il piano di esecuzione query.
Come ho già detto in precedenza, l'analisi del piano di esecuzione è una delle principali esigenze per garantire buone prestazioni della query. Il piano di esecuzione descrive il percorso utilizzato dai Optimizer di SQL Server per arrivare a dei dati richiesti e mostra quali operazioni fossero state eseguite nel corso della elaborazione delle query. Nel piano di esecuzione, ogni operazione è rappresentata da un'icona e una serie di frecce che uniscono queste icone. In questo modo è facile capire caratteristiche prestazionali di una query.
Per vedere piano di esecuzione di una query, immettere Query Analyzer di SQL Server 2000 o editor di query di SQL Server 2005, scrivere la query e digitare Ctrl + L o selezionare l'opzione di menu Query> Visualizza piano di esecuzione stimato nella barra dei menu.
Noterete che la query non viene effettivamente eseguito, che si verificherà solo prima della creazione del piano di esecuzione. Quando si analizza un piano di esecuzione, è necessario avere in mente che è generato in base alle statistiche esistenti per la tavola o gli indici utilizzati dalla query, quindi è molto importante che quando si analizza il piano di esecuzione l'accesso oggetti statistiche vengono aggiornate.
Se le statistiche non sono aggiornate, il piano di esecuzione verrà generato in cima dati incoerenti che possono non riflettere la realtà. Si deve sempre aggiornare le statistiche dopo aver eseguito le operazioni che mettono in moto grandi fasci di dati o la creazione e l'alterazione degli indici.
Nella figura 1 abbiamo l'esempio del piano di esecuzione di una query eseguita sulle tabelle Editori e il titolo del database Pubs di SQL Server 2000.
Figura 1. Esempio di un piano di esecuzione
Si osservi che ogni icona rappresenta una specifica operazione e le frecce indicano il percorso da seguire. La freccia rossa indica che l'analisi deve sempre essere eseguita da destra verso sinistra e dall'alto verso il basso.
Piano di esecuzione
Il piano di esecuzione descrive il percorso utilizzato da ottimizzatore di SQL Server per raggiungere i dati richiesti e mostra quali operazioni sono state eseguite lungo l'elaborazione della query.
2. Quando si analizza il piano di esecuzione, inizia la ricerca di operazioni con un alto consumo.
Durante l'analisi del piano di esecuzione, alla ricerca di iniziare le operazioni che hanno un alta percentuale di consumo. Alla ricerca di operazioni con un alto consumo consente di disporre in ordine di priorità, che problema dovrebbe essere "attaccato" per primo. Tra le operazioni che hanno un maggiore consumo e che, pertanto, deve essere prevenuto abbiamo:
· Tabella e le operazioni Index Scan;
Operazioni · che hanno frecce troppo "densa";
· Ricerche Bookmark operazioni;
· Operazioni di ordinamento.
Di tabelle e indici delle operazioni di scansione
Scansioni tavolo e scansioni Indice operazioni sono operazioni lente e che generano un elevato consumo di server. Questo perché queste sono operazioni che navigare attraverso tutte le righe della tabella o l'indice, eseguendo una pulizia sequenziale e restituendo le linee che soddisfano la clausola in cui (sempre che si utilizza una clausola where).
E 'vero che a seconda delle dimensioni della tavola, la quantità di linee di ritorno, e che la qualità della regola di filtro, Table Scan non può puntare un problema, ma soprattutto, quando si parla di grandi tavole, la Table Scan è la peggiore di tutte le operazioni e indica che la tabella non ha indice o, se lo è, non viene utilizzato in modo adeguato dalla query.
Ogni volta che trovate una scansione di tabella nel piano di esecuzione, non trattenersi dal indagarlo. L'indice di scansione e Clustered Index Scan esegue una travolgente sequenza di pagine di indice di una tabella. Dal momento che agiscono su un indice, sono migliori rispetto alla tabella di scansione, ma anche meritano un'indagine. Questo perché, in generale, se avete Index Scan, poi una grande quantità di dati viene restituito e nella maggior parte delle volte non avete bisogno di tutti questi dati.
Le scansioni, nella loro maggioranza, sono risolti attraverso la modifica o la creazione di indici appropriati. Alcune soluzioni includono anche modificare la query in modo da essere più selettivi, cioè, di utilizzare la clausola WHERE per filtrare al massimo possibile i registri restituiti.
La figura 2 mostra la rappresentazione grafica della tabella, cluster Indice di scansione e indice operatori di scansione.
Figura 2. Rappresentazione grafica della tabella, cluster Indice di scansione e indice operatori di scansione
Le operazioni che hanno frecce troppo "densa"
Le frecce non sono operatori: sono semplicemente utilizzati per unire un operatore ad un altro. Attraverso le frecce che abbiamo una stima della quantità di linee interessate dall'operazione in quanto il suo spessore è direttamente proporzionale alla quantità di linee restituito dall'operazione.
Più grande è lo spessore della freccia, maggiore è la quantità di linee coinvolte nel funzionamento o la quantità di linee passato da un operatore ad un altro. In modo per voi di vedere la quantità e la stima della numerosità delle linee interessate, è sufficiente posizionare il cursore sulla freccia.
Quando si analizza il piano di esecuzione, sempre dare una particolare attenzione alle frecce più spesso, per una freccia molto spesso può indicare un funzionamento ad alta di contenimento di I / O e, di conseguenza, nel sottosistema disco del server.Un altro punto importante è che il più delle volte, le frecce molto spesso sono associate a una scansione di tabella.
Per risolvere questo tipo di problema, dobbiamo ancora una volta fare uso della clausola WHERE per filtrare i dati restituiti e fare la freccia più sottile possibile. Se la freccia è associata a una scansione di tabella, prima di analizzare il secondo, perché probabilmente quando la soluzione del Table Scan potrete risolvere anche lo spessore della freccia. Il suggerimento è: evitare di ottenere linee più del necessario.
Nella Figura 3 abbiamo piano di esecuzione di una query (tabella Employee modificata del database Pubs) che restituisce circa 700 migliaia di record. Si osservi che la query non utilizzare la clausola where.
Figura 3. Piano di esecuzione per una query senza clausola where
Bookmark Operazioni ricerche
L'operatore di ricerca preferiti avviene quando l'indice può essere utilizzato per soddisfare il criterio di ricerca, ma non ha tutti i dati richiesti dalla query.Normalmente si verifica insieme ad un Index Scan quando la query richiede informazioni sulle colonne che non fanno parte della chiave di indice. In questo scenario, per cercare di ricerca preferiti, che ha un alta percentuale di consumo.
Nella Figura 4 si può osservare che, per ottenere i dati richiesti dalla query, SQL Server esegue un'operazione di ricerca preferiti, che consuma il 41% del tempo totale della query di esecuzione.
Figura 4. Piano di esecuzione con una ricerca Bookmark
Questo è accaduto perché il fname e le colonne lname non fanno parte della chiave di indice, che è composto solo della colonna hire_date, e con quella di SQL Server deve accedere a pagine di dati della tabella al fine di ottenere i dati relativi fname e lname.
Se il costo di ricerca preferiti operazione è troppo alta, controllare se un indice cluster o non cluster indice, composto dalle colonne ricercato, può essere utilizzato.Nella Figura 5, la creazione di un indice cluster composto dal fname e colonne lname risolto il problema.
Figura 5. Piano di esecuzione dopo la creazione di un indice cluster
Un consiglio: sempre quando è possibile evitare l'operazione di ricerca preferiti nella query. Questo perché, anche se la ricerca segnalibro che si occupa di piccole quantità di dati non è un problema, questa operazione in grande quantità di dati aumenta la velocità di I / O e di conseguenza danneggia le prestazioni delle query.
Le operazioni di smistamento
L'operazione di ordinamento ajust tutte le linee in ordine crescente o decrescente, a seconda della clausola Order By delle sue query. Operazioni di ordinamento, oltre ad utilizzare il database di sistema tempdb per una zona di stoccaggio temporaneo, anche aggiungere un grande I / O tasso per le operazioni.
Quindi, se siete abituati a vedere l'operatore Sort di frequente nelle sue query e questo operatore è un'operazione di alto consumo, provare a rimuovere la clausola menzionati. D'altra parte, se si sa che sarà sempre organizzare la vostra query da una colonna specifica, si consideri che l'indicizzazione.
Nel comando Crea indice è possibile determinare la direzione di ordinamento (ASC o DESC) di un determinato indice. Figura 6 presenta un'operazione di ordinamento consuma il 23% del tempo totale di esecuzione della query.
Figura 6. Operazione di ordinamento con il 23% dei consumi
3. Evitare l'uso di cursori e quando possibile li sostituire "mentre".
Il grande problema nell'uso dei cursori è che questi, per loro natura sono lenti e consumano una grande quantità della risorsa server. Ciò accade perché il database relazionali sono ottimizzati per lavorare con set di record.
Ogni set di record è conosciuto come set di risultati e trattato come una singola unità.Come esempio, il set di record restituiti da un'istruzione Select consiste di tutte le linee che soddisfano la condizione della clausola WHERE.
Il cursore va nella direzione opposta di questo concetto, dal momento che è stato sviluppato pensando alla linea di lavoro per riga. Cioè, lo si usa per navigare riga per riga all'interno di un set di record o un set di risultati restituito da un'istruzione Select.
Come conseguenza di questo uso, abbiamo un grande volume di pacchetti inviati attraverso la rete, il tempo di compilazione alta e analizzare il Fetch dichiarazioni, il blocco dei collegamenti a causa dei blocchi nelle tabelle o record, infine, un elevato consumo di risorse del server e basso rendimento della sua applicazione.
Di fronte a questo, alcuni metodi emersi utilizzando Transact SQL, che può essere utilizzato per sostituire l'uso dei cursori. In seguito, mi presenterà due di questi metodi.
In primo luogo, in modo che tu possa capire come il cursore è utilizzato, nel Listato 1 abbiamo un esempio molto semplice di cursore che naviga riga per riga nella tabella Authors del database Pubs, visualizzando le informazioni del id, nome e cognomecampi.
Listato 1. Esempio di utilizzo del cursore
1. DECLARE @ au_id varchar (15)
2. DECLARE @ au_fname varchar (15)
3. DECLARE @ au_lname varchar (15)
4. DECLARE CURSOR cur_authors
5. PER SELEZIONARE au_id, au_fname, au_lname FROM autori
6. Cur_authors OPEN
7. FETCH NEXT FROM cur_authors IN au_id @, @ au_fname,
@ Au_lname
8. MENTRE @ @ FETCH_STATUS = 0
9. BEGIN
10. SELECT @ au_id, au_fname @, @ au_lname
11. FETCH NEXT FROM cur_authors IN @ au_id,
@ Au_fname, @ au_lname
12. FINE
13. Cur_authors CHIUDI
14. DEALLOCATE cur_authors
Nell'esempio, dalle linee 1-3 abbiamo la dichiarazione delle variabili che verranno utilizzate per memorizzare i dati dei campi restituiti da selezionare. E 'importante osservare che queste variabili devono avere lo stesso tipo di dati delle colonne della tabella
Nelle linee 4 e 6, abbiamo la dichiarazione e l'apertura del cursore stesso. Si osservi che il set di risultati generato all'apertura del cursore include tutti i record e solo le colonne au_id, au_fname e au_lname della tabella autori. In linea 7, Fetch successiva si fa carico di prendere il record successivo e compilando le variabili con i dati ottenuti dal record.
Dalle linee da 8 a 12, abbiamo il ciclo che continuerà a essere giustiziato per tutto il tempo in quanto vi sono ancora record (@ @ FETCH_STATUS = 0). In pratica, la linea 8 verifica se è ancora record, se ci sono, in linea 10 "stampe" il contenuto delle variabili sullo schermo e nella riga 11, prende il record successivo di nuovo e riempie le variabili con i dati ottenuti in il record.
Nella riga 13, abbiamo la chiusura del cursore e alla riga 14 il rilascio della memoria utilizzata dal cursore si svolge. Dato l'esempio, vedremo due metodi che possono essere utilizzati per eseguire la stessa operazione, ma senza l'uso di cursori.
Il primo metodo, che viene presentato nel Listato 2, si avvale di tabella temporanea e la clausola di Top. Con questo metodo, si crea uno snapshot delle informazioni desiderate gettare il risultato di selezionare in una tabella temporanea.
Listato 2. Metodo per sostituire il cursore con tabella temporanea
1. DECLARE @ au_id char (11)
2. SELECT au_id, au_fname, au_lname
IN # tb_tmp_authors FROM autori
3. SELECT TOP = 1 @ au_id au_id FROM # tb_tmp_authors
4. MENTRE @ @ ROWCOUNT <> 0
5. BEGIN
6. SELECT au_id, au_fname, au_lname
8. DA DOVE # tb_tmp_authors au_id = @ au_id
9. DELETE # tb_tmp_authors DOVE au_id = @ au_id
10. SELECT TOP = 1 @ au_id au_id FROM # tb_tmp_authors
11. FINE
12. DROP TABLE # tb_tmp_authors
Nel metodo del Listato 2, riga 1 dichiara semplicemente una variabile per memorizzare il contenuto della colonna au_id. In linea 2, abbiamo la stessa Select che è stato utilizzato nel Listing 1 dichiarazione del cursore. La differenza è qui che invece di buttare il risultato della Selezione in un cursore, questo risultato è stato gettato in una tabella temporanea denominata # tb_tmp_authors.
Dopo il carico tabella temporanea, possiamo lavorare con esso a che fare con la linea registri per riga. Si osservi che nella riga 3 la clausola TOP viene utilizzata con valore 1. La Top 1 clausola assicura che solo il primo record della tabella temporanea sarà restituito da selezionare e di conseguenza avremo il valore della colonna au_id dal primo record memorizzato nella variabile @ au_id.
Nella riga 4, mentre il comando è usato per fare la Loop e per controllare il valore della variabile @ @ conteggio delle righe globale. Si tratta di una variabile di sistema che viene automaticamente riempito con la quantità di record interessati dalla Seleziona eseguito in linea 3. Dal momento che usiamo nella Top 1 nel Select, questo effetto sarà sempre un record alla volta e la variabile @ @ conteggio delle righe sarà sempre 1 fino a quando la tabella temporanea è vuota.
Da righe da 6 a 10 sono poi eseguiti tutti i trattamenti desiderati, in questo caso abbiamo solo stampare i dati nella schermata, e osservare che, in linea 9 il record della tabella temporanea au_id cui è stato ottenuto nella Selezione della linea 3 è esclusa .
Questo farà in modo che il secondo record della tabella temporanea diventa il primo.Nella riga 10 la stessa Selezione della linea 3 è ancora una volta eseguito prendendo il valore dal primo record del au_id colonna. E così il processo continuerà fino a quando la tabella temporanea è vuota e con questo @ @ conteggio delle righe è uguale a 0. Alla fine del trattamento, la linea 12 esclude la tabella temporanea.
Il secondo metodo, che viene presentato nel Listato 3, non usa una tabella temporanea, ma usa il Min () per prendere un record alla volta dalla tabella authors.
Lista 3. Metodo per sostituire il cursore con il Min () funzione
1. DECLARE @ au_id char (11)
2. SELECT @ au_id = min (au_id) di autori
3. MENTRE @ au_id non è nullo
4. BEGIN
5. SELECT au_id, au_fname, au_lname FROM autori
6. DOVE au_id = @ au_id
7. SELECT @ au_id = min (au_id) FROM autori
DOVE au_id> @ au_id
8. FINE
Dato che il metodo utilizza la funzione min () è necessario garantire che la verifica è fatta più di una colonna che è single e mezzaluna. Questo garantirà che le nuove linee avranno sempre un identificatore più grande l'identificativo della linea in fase di elaborazione.
In questo esempio, nella linea 1 abbiamo la dichiarazione della variabile che memorizza il contenuto della colonna au_id. In linea 2, la Selezione ottiene dalla tabella authors il record che ha il valore minore per la colonna au_id e memorizza questo valore nella variabile @ au_id.
Nella riga 3, mentre il comando è usato per fare la Loop e per verificare se la variabile @ au_id non è nullo, perché quando si è nullo vuol dire che nessun record di più di essere trattati esistenti e con questo lasciamo il Loop. Essendo la variabile @ au_id diverso da quello nullo, abbiamo poi entrare nel loop e da linee da 5 a 7 abbiamo eseguire l'elaborazione desiderata.
In questo caso abbiamo solo stampare i dati sullo schermo e in linea 7 si ottiene un nuovo record in cui il valore della colonna au_id è maggiore del valore già memorizzato nella variabile @ au_id. E così l'elaborazione continua fino a raggiungere l'ultimo record della tabella.
Come abbiamo visto, non sempre abbiamo bisogno di usare il cursore per elaborare i nostri dati all'interno del server SQL. Se si esegue i tre esempi citati qui vedrete che il risultato sarà lo stesso.
4. Sostituire l'operatore UNION da UNION ALL, quando possibile.
Quando si utilizza l'operatore UNION per combinare il risultato di due query, tenere presente che questa esegue una SELECT DISTINCT nel risultato finale per rimuovere eventuali record duplicati, anche se non ci sono record duplicati.
Prima di questo, il consiglio è che non avendo la possibilità di record duplicati o se ci sono problemi per l'applicazione che il risultato finale presenta duplicazioni, utilizzare l'operatore UNION ALL. Dato che questo operatore non esegue SELECT DISTINCT nel risultato finale, utilizza meno risorse di SQL Server e, quindi, migliora le prestazioni delle query.
In figura 7 abbiamo due query che eseguono la stessa operazione sulla tabella Ordini del database Northwind, uno utilizzando l'operatore e l'altro dell'Unione, l'Unione Tutti.
Si osservi che la query con Unione Tutti mostrerà tutti i record compresi i duplicati.Ma questa consuma meno delle risorse del server per non eseguire la SELECT DISTINCT nel risultato finale.
Figura 7. Esempio di query utilizzando l'Unione e l'Unione Tutti gli operatori
5. Sostituire sub-query join.
Molte istruzioni Transact SQL che fanno uso di sub-query può essere riscritta utilizzando join. E 'vero che molte delle volte non avrete benefici prestazioni quando si usano sub-query o join, ma in alcuni casi in cui, per esempio, l'esistenza di un valore deve essere verificato, l'uso di join produrranno risultati migliori.
Così è, se possibile cercare di sostituire il sub-query di join. Nel Listato 4 abbiamo due istruzioni Seleziona essendo uno scritto con sub-query e l'altra con unirsi.
Listato 4. Seleziona le istruzioni tramite sub-query e unisciti
- L'istruzione SELECT che utilizza sub-query
SELECT ProductID, IDFornitore, ProductName
FROM Prodotti WHERE IDFornitore IN
(SELECT IDFornitore da fornitori
WHERE (paese = 'Brasile'))
- L'istruzione SELECT che utilizza unirsi
SELECT prd.ProductID, prd.SupplierID, prd.ProductName
DA Prodotti PRD INNER JOIN Fornitori sup
ON prd.SupplierID = sup.SupplierID
DOVE sup.country = 'Brasile'
Osservare che quando viene eseguito sia produrrà lo stesso risultato: una lista con tutti i prodotti dei fornitori in Brasile.
6. Nella clausola WHERE non utilizzare colonna indicizzata nelle funzioni.
Il modo più semplice per fare una colonna non in grado di essere indicizzato, è di mettere questa colonna in una funzione! In SQL Server, l'uso della funzione di sottostringa nella clausola WHERE è ogni comune, tuttavia, quello che pochissimi sanno è che quando si inserisce una colonna indicizzata all'interno di una funzione, di SQL Server non finisce con l'indice in modo conveniente e molte volte non ha nemmeno utilizzarla affatto.
In queste situazioni, la cosa migliore da fare è spostare la funzione dall'altra parte dell'equazione nella clausola in cui, se possibile, o non lo usano affatto. Nella Figura 8 abbiamo un esempio di come l'uso della funzione di colonna indicizzata nella clausola WHERE può impedire l'SQL Server di utilizzare l'indice corretto.
Figura 8. Esempio di query utilizzando la funzione SUBSTRING e il comando LIKE
Le due interrogazioni presentate in Figura 8 hanno come obiettivo di ottenere tutti i dipendenti il cui nome inizia con i caratteri "Ma". Si osservi che nella prima query la funzione sottostringa viene utilizzato per rompere la colonna fname prendendo solo i primi due caratteri e confrontandole con la stringa "Ma".
Dal momento che non SQL Server sa quale sarà il carattere da ricercare, il processo viene eseguito per ciascuna delle linee della tabella, finisce per l'esecuzione di un Index Scan, spazzando tutte le pagine di indice in modo sequenziale.
Nella seconda query la funzione è stata sottratta dal comando Like. In questo caso, dal momento che la colonna indicizzata non è interessato, di SQL Server riesce a utilizzare l'indice in modo adeguato l'esecuzione di un Index Seek nelle pagine di indice.
7. Quando è possibile cerca di utilizzare gli operatori che sono in grado di essere indicizzato.
Simile al problema dell'uso di colonne indicizzate nelle funzioni, c'è anche un insieme di operatori che, quando utilizzati, possono evitare che il SQL Server di utilizzare l'indice in modo conveniente. Questi sono conosciuti come operatori in grado di essere indicizzato.
Gli operatori positivi sono generalmente in grado di essere indicizzati: =,>,> =, <, <=, Tra e Come quando utilizzati nel: Come maniera '% parola'. Gli operatori negativi sono generalmente incapaci di essere indicizzati: <>, Non, non esiste, non in, Non Mi Piace Come e quando viene utilizzato in: Come maniera 'parola%'.
8. Quando ha bisogno di ottenere una quantità di record forma un tavolo, evitare di utilizzare il Select Count (*).
Ogni volta che abbiamo bisogno di ottenere la quantità di record da una tabella, il primo T-SQL istruzione che viene in mente è: "Select Count (*) Dalla tabella".
Il problema con questa istruzione è che il più delle volte svolge una tabella o Index Scan per riportare la quantità di record nella tabella. Per tabelle di grandi dimensioni questo è un sinonimo di query lenta e un elevato consumo di risorse del server.
Un modo più semplice per eseguire la stessa operazione senza causare impatto utilizzando la tabella dei sistemi chiamati sysindexes. Questa tabella ha una colonna chiamata righe che memorizza la quantità totale di record per ogni tabella del database.
Essendo così, quando è possibile usare il T-SQL istruzione che segue, per ottenere la quantità di record nella tabella.
Selezionare le righe da sysindexes
WHERE id = OBJECT_ID ('nome_tabella') E indid <2
Poiché la tabella sysindexes non ha una colonna con il nome delle tabelle, ma solo i loro identificativi, l'istruzione utilizza il OBJECT_ID () in modo che il server SQL può, con il nome della tabella, identificare il suo id rispettivi all'interno del sysindexestavolo.
9. Utilizzare sempre il SET NOCOUNT ON all'interno di stored procedure.
Si tratta di una "best practice" che io uso raramente vedere gli sviluppatori.Sicuramente durante l'esecuzione di istruzioni T-SQL, come Select, Insert, Update e Delete è necessario aver già visto il "nn fila (s) affected" facendo parte del messaggio del risultato della query.
Forse non lo so, ma questo messaggio apparentemente innocuo può generare un grande impatto nello svolgimento della vostra stored procedure. Questo perché quando si esegue un SP che ha diverse istruzioni T-SQL, questo messaggio viene inviato al client per ogni istruzione all'interno del PS, che finisce per generare un inutile traffico di rete.
L'opzione SET NOCOUNT disabilita l'invio di questi messaggi. Con questo, la SP che possiedono diversi T-SQL istruzioni, può presentare un significativo miglioramento delle prestazioni una volta che il traffico di rete sarà notevolmente ridotto.
10. Durante la creazione di indice composto, per le colonne dell'indice, in modo da soddisfare la clausola Where della maggior parte delle vostre domande.
Una cosa che deve sempre essere tenuto presente quando si lavora con composti (indici con due o più colonne della tabella), è che l'indice verrà utilizzato soltanto dalla query se la prima colonna della chiave di un indice composto è specificata nel la clausola WHERE.
Pertanto, quando si lavora con indice composto, l'ordine delle colonne dell'indice è molto importante. Per farvi capire meglio, passiamo ad un esempio: supponiamo che il database ha una tabella chiamata tb_employee e che questa tabella ha un indice composto dal cognome colonne, first_name in questo ordine rispettivo.Quando si analizza il piano di esecuzione di una query che ha la clausola WHERE come:
dove cognome = 'Pinheiro'
Vedrete che l'indice è stato adeguatamente utilizzato dallo Strumento per ottimizzare la consultazione di SQL Server, ma quando si analizza il piano da una consultazione che ha la clausola WHERE come:
dove fist_name = 'Nilton'
Vedrete che l'indice non è stato utilizzato. Pertanto, quando si utilizza indici composti, assicurarsi che la clausola in cui si è sempre la prima colonna dell'indice.
Conclusione
Come abbiamo visto, innumerevoli sono le risorse e le tecniche che possiamo utilizzare per estrarre un profitto migliore di SQL Server. In generale, quando lavoriamo con i problemi di prestazioni in query, uno dei punti fondamentali è quello di assicurare che le tabelle sono indici e soprattutto garantire che le query stanno facendo uso corretto di questi indici.
L'analisi del piano di esecuzione può aiutare in questo. Un altro punto importante è quello di garantire che le statistiche siano sempre aggiornati. Ricordate che Optimizer di SQL Server utilizza le statistiche di prendere le sue decisioni. Saluti e si vede la prossima volta.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.