Ho eseguito uno strumento di autoindicizzazione sul nostro database MS SQL (ho modificato uno script proveniente da Microsoft che esamina le tabelle delle statistiche dell'indice - Indicizzazione automatica automatizzata ). Dalle statistiche, ora ho un elenco di consigli per gli indici che devono essere creati.

Modifica: gli indici sopra descritti prendono le informazioni dai DMV che indicano ciò che il motore di database userebbe per gli indici se fossero disponibili e gli script prendono le raccomandazioni Top x (per ricerche, impatto dell'utente ecc.) E le inseriscono in una tabella.

(Modifica sopra parzialmente tratto dalla risposta di Larry Coleman sotto per chiarire cosa stanno facendo gli script)

Dato che sono nuovo nell'amministratore del database e dopo aver effettuato una rapida ricerca in rete, sono riluttante a fare il grande passo e ad aggiungere ciecamente gli indici consigliati. Tuttavia, non avendo esperienza sul campo, sto cercando alcuni consigli su come determinare se le raccomandazioni sono necessarie o meno.

Devo eseguire SQL Profiler o è meglio esaminare il codice che richiede le tabelle? E hai qualche altro consiglio?

Uso gli script di analisi dell'indice di Jason Strate (Vecchia posizione) . Ti dicono quanto vengono utilizzati gli indici esistenti e quanti indici mancanti sarebbero stati utilizzati. In genere non aggiungo indici a meno che non costituiscano oltre il 5 o il 10% delle query su una tabella.

Ancora più importante, tuttavia, si tratta di assicurarsi che l'applicazione risponda abbastanza velocemente per gli utenti.

Aggiornamento: articoli del blog di analisi dell'indice di Jason Strate per script più recenti (Nuova posizione)

Doppio aggiornamento: In questi giorni, utilizzo sp_BlitzIndex® quando eseguo l' analisi dell'indice.

Ci sono alcuni concetti e termini che sono importanti da capire quando si tratta di indici. Ricerche, scansioni e ricerche sono alcuni dei modi in cui gli indici verranno utilizzati tramite istruzioni selezionate. La selettività delle colonne chiave è fondamentale per determinare l'efficacia di un indice.

Una ricerca si verifica quando lo Strumento per ottimizzare le query di SQL Server determina che il modo migliore per trovare i dati richiesti è la scansione di un intervallo all'interno di un indice. Le ricerche in genere si verificano quando una query è "coperta" da un indice, il che significa che i predicati di ricerca si trovano nella chiave dell'indice e le colonne visualizzate sono nella chiave o incluse. Una scansione si verifica quando lo Strumento per ottimizzare le query di SQL Server determina che il modo migliore per trovare i dati è scansionare l'intero indice e quindi filtrare i risultati. Una ricerca si verifica in genere quando un indice non include tutte le colonne richieste, nella chiave dell'indice o nelle colonne incluse. Query Optimizer utilizzerà quindi la chiave cluster (rispetto a un indice cluster) o il RID (rispetto a un heap) per "cercare" le altre colonne richieste.

In genere, le operazioni di ricerca sono più efficienti delle scansioni, a causa della query fisica di un set di dati più piccolo. Ci sono situazioni in cui non è così, come un set di dati iniziale molto piccolo, ma che va oltre lo scopo della tua domanda.

Ora, hai chiesto come determinare l'efficacia di un indice e ci sono alcune cose da tenere a mente. Le colonne chiave di un indice cluster sono chiamate chiavi cluster. Ecco come i record sono resi unici nel contesto di un indice cluster. Tutti gli indici non cluster includeranno la chiave cluster per impostazione predefinita, al fine di eseguire ricerche quando necessario. Tutti gli indici verranno inseriti, aggiornati o eliminati per ogni rispettiva istruzione DML. Detto questo, è meglio bilanciare i guadagni in termini di prestazioni in dichiarazioni selezionate rispetto a risultati positivi nelle istruzioni di inserimento, eliminazione e aggiornamento.

Per determinare l'efficacia di un indice, è necessario determinare la selettività delle chiavi dell'indice. La selettività può essere definita come una percentuale di record distinti rispetto ai record totali. Se ho una tabella [person] con 100 record totali e la colonna [first_name] contiene 90 valori distinti, possiamo dire che la colonna [first_name] è selettiva al 90%. Maggiore è la selettività, più efficiente è la chiave di indice. Tenendo presente la selettività, è meglio inserire prima le colonne più selettive nella chiave di indice. Usando il mio esempio [persona] precedente, se avessimo una colonna [last_name] selettiva al 95%? Vorremmo creare un indice con [last_name], [first_name] come chiave dell'indice.

So che questa è stata una risposta un po 'prolissa, ma ci sono davvero molte cose che determinano l'efficacia di un indice e molte cose su cui devi valutare qualsiasi miglioramento della performance.

Di recente ho scoperto una fantastica sceneggiatura gratuita delle persone su BrentOzar Unltd http://www.brentozar.com/blitzindex/

Questo fa una buona analisi di quali indici esistono, quanto spesso vengono usati e quanto spesso il motore di query sta cercando un indice che non esiste.

La sua guida è generalmente buona. A volte diventa un po 'troppo suggestivo di idee. Finora ho generalmente fatto quanto segue:

• Indici rimossi che non sono mai stati letti (o forse meno di 50 volte al mese).
• Aggiunti gli indici più ovvi su chiavi e campi esterni che so che usiamo molto.

Non ho aggiunto tutti gli indici consigliati e sono tornato indietro una settimana dopo per scoprire che non sono più consigliati poiché il motore di query utilizza invece alcuni degli altri nuovi indici!

Generalmente dovresti evitare gli indici su:

• Tabelle molto piccole (meno di 50-200 record): spesso il motore di query è più veloce se esegue la scansione della tabella anziché caricare l'indice, leggere, elaborarlo ecc.
• Evita gli indici su colonne con Cardinalità bassa ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ) sulla prima colonna menzionata. Ad esempio, l'indicizzazione di un campo di genere (M / F) è di scarsa utilità, è altrettanto pratico scansionare la tabella e trovare il ~ 50% corrispondente. Se è elencato dopo qualcosa di più specifico nell'indice (ad es. [Data di nascita, sesso]) è meglio - potresti voler far nascere tutti i maschi in un determinato arco di tempo.

Gli indici cluster sono buoni - normalmente si basano sulla chiave primaria. Aiutano il motore di database a mettere in ordine i dati sul disco. Molto essenziale per capirlo per le tabelle più grandi in quanto un buon indice cluster spesso riduce lo spazio occupato dalla tabella.

Ho ridotto alcuni tavoli da 900 MB a 400 MB, solo perché in precedenza erano cumuli non strutturati. http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx

Riorganizzare / Rebuild

Dovresti cercare di verificare la presenza di indici frammentati. Un po 'di frammentazione va bene, non diventare ossessivo! http://technet.microsoft.com/en-us/library/ms189858.aspx Conosci la differenza tra riorganizza e ricostruisci!

Rivedi regolarmente

Le query cambiano, i volumi di dati cambiano, vengono aggiunte nuove funzionalità, rimosse quelle vecchie. Dovresti guardarli una volta al mese (o più spesso se hai volumi elevati) e cercare dove puoi aiutare il database!

Quanti

In un video recente, Brent consiglia (in genere) non più di 5 indici su una tabella con molta scrittura (ad es. Tabella degli ordini) e non più di 10 se viene letto molto più di quanto scritto (ovvero tabella di registrazione per analisi) http: / /www.youtube.com/watch?v=gOsflkQkHjg

Complessivamente

Dipende!

Il chilometraggio varia in base al database. Copri l'ovvio (cognome del dipendente, data dell'ordine ecc.) Sui tuoi tavoli (attuali / futuri) più grandi. Monitorare, rivedere e adattare, se necessario. Dovrebbe essere parte dell'elenco di controllo di routine quando si gestiscono i database :)

Spero che sia di aiuto!

Normalmente si ha un carico di lavoro specifico (query) e si verifica attentamente l'impatto di ogni nuovo indice sul carico di lavoro. Questo processo iterativo dovrebbe sempre includere un'attenta analisi dei piani di esecuzione, che rivelerebbe quali indici vengono utilizzati. L'argomento dell'analisi di una query è lungo e iniziare con il capitolo MSDN dedicato L' analisi di una query è una buona scommessa.

A volte, quando il carico di lavoro è troppo complesso o la conoscenza della progettazione del database è imprecisa, si utilizza il Database Engine Tuning Advisor , che esegue un'analisi automatica del carico di lavoro e propone alcuni indici. Le proposte dovrebbero ovviamente essere attentamente analizzate e l'impatto dovrebbe essere misurato immediatamente.

Quindi se segui la mia idea, aggiungere un indice e misurare l'impatto è davvero solo un caso di test A / B : esegui il tuo carico di lavoro senza l'indice come linea di base, quindi lo esegui con l'indice, misuri e confronti con la linea di base e quindi decidere, in base alle metriche osservate e misurate, se l'impatto è benefico. Il carico di lavoro è meglio una suite di test di buona qualità, ma può anche essere una riproduzione di un carico di lavoro acquisito, vedere Procedura: riprodurre un file di traccia .

Una risposta più sintetica è guardare il punto di sys.dm_db_index_usage_statsvista e vedere come vengono utilizzati gli indici, ma di solito si tratta di un approccio per fare analisi in loco su un carico di lavoro sconosciuto (cioè un consulente chiamato ad aiutare probabilmente inizierà con questo).

A partire da SQL 2005, SQL Server ha DMV che indicano quale motore di database userebbe per gli indici se fossero disponibili. Le viste possono indicare quali colonne dovrebbero essere colonne chiave, quali colonne dovrebbero essere incluse e, soprattutto, quante volte l'indice sarebbe stato utilizzato.

Un buon approccio sarebbe quello di ordinare la query degli indici mancanti in base al numero di ricerche e considerare di aggiungere prima gli indici principali.

^{Vedi anche: i documenti ufficiali MS DMV}

Dipende da come viene utilizzata quella tabella. ad esempio diciamo che ho una tabella che viene letta molte volte ma che aggiornamenti e inserimenti sono rari. Inoltre, interrogo sempre la tabella su una colonna di chiave esterna. Avrà senso creare un indice (non cluster) su quella chiave esterna per accelerare le query di lettura. Ma il rovescio della medaglia è che l'inserimento, l'aggiornamento diventerà lento.

Esistono poche query statistiche che indicano quanto tempo impiegano le query. Inizia con quelli più lenti. Se il predicato della query non ha indice, sarà utile crearne uno.