it-swarm.it

Come determinare se un indice è richiesto o necessario

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 raccolgono informazioni dai DMV che indicano quale motore di database userebbe per gli indici se fossero disponibili e il 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)

Poiché 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 alla cieca 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?

112
misterjaytee

Uso script di analisi dell'indice di Jason Strate (posizione precedente) . 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.

81

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 attraverso 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, sia nella chiave di indice che 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 istruzioni selezionate rispetto a risultati positivi in ​​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.

51
Matt M

Di recente ho scoperto una fantastica sceneggiatura gratuita della gente di 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ù raccomandati 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. Per 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 che tutti i maschi nascano 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 poiché 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

Riorganizza/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 far parte dell'elenco di controllo di routine quando si gestiscono i database :)

Spero che sia di aiuto!

29
Greg Robson

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 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 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, misurare e confrontare 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 sys.dm_db_index_usage_stats guarda e vedi 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).

14
Remus Rusanu

A partire da SQL 2005, SQL Server ha DMV che ti dice quale motore di database userebbe per gli indici se fossero disponibili. Le viste possono indicare quali colonne dovrebbero essere le 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

8
Larry Coleman