È corretto aggiungere ciecamente indici mancanti?

Uso spesso SSMS per testare le mie stored procedure lente per gli indici mancanti. Ogni volta che vedo un "indice mancante (Impact xxx)" la mia reazione istintiva è semplicemente quella di creare il nuovo indice. Ciò si traduce in una query più veloce ogni volta che posso dire.

Qualche motivo per cui non dovrei continuare a farlo?

Molte ragioni.

Uno dei più grandi che mi viene in mente è che i DMV dell'indice mancante non tengono conto degli indici esistenti.

Esempio:

Hai un tavolo con ColA, ColB, ColC.

Attualmente hai un indice attivo ColA. L'indice DMV mancante ti suggerirà di aggiungere un indice (ColA, ColB). Questo può essere corretto, ma la cosa intelligente da fare è aggiungere ColBuna seconda chiave all'indice esistente. Altrimenti hai una copertura duplicata, spazio sprecato e spese generali.

Allo stesso modo, se hai un indice attivo ColB INCLUDE (ColA), può suggerire un indice attivo ColB INCLUDE (ColC). Ancora una volta la cosa intelligente da fare è aggiungere ColCall'elenco di inclusione nell'indice esistente.

Gli indici suggeriti hanno una vista estremamente ristretta: guardano solo una singola query o un'unica operazione all'interno di una singola query. Non tengono conto di ciò che esiste già o degli altri schemi di query.

Hai ancora bisogno di un essere umano pensante per analizzare la strategia di indicizzazione generale e assicurarti che la struttura dell'indice sia efficiente e coerente.

Se non ci fossero problemi con la semplice aggiunta di tutti gli indici suggeriti, non sarebbe neppure necessario suggerirli: verrebbero implementati automaticamente.

Raccomando un uso prudente di questa tecnica di ottimizzazione poiché ho scoperto che i suggerimenti sugli indici mancanti spuntati dai piani di query sono costantemente meno affidabili poiché le query e gli schemi DB diventano progressivamente più complessi. Ciò è stato dovuto a una serie di motivi nella mia esperienza:

1) Il "miglioramento percentuale" può essere lontano da tutti tranne le query più semplici / gli indici più evidenti, dopo tutto è solo una stima e non deriva dai costi effettivi sostenuti o dai conteggi effettivi quando viene eseguita la query. Ho visto aumentare i costi delle query dopo l'implementazione di un indice suggerito o non viene nemmeno utilizzato e il piano rimane lo stesso.

2) Il piano di query in sé non è ottimale, né a causa della costruzione della query (join e dove clausola non ottimizzata, ecc.), O le stime del conteggio delle righe sono disattivate a causa di statistiche mancanti / non aggiornate. L'indicizzazione su un piano di query brutalmente cattivo è spesso nella migliore delle ipotesi una soluzione di cerotto con solo un miglioramento incrementale delle prestazioni.

3) Potresti non vedere l'intera immagine. Ciò è particolarmente vero quando si utilizza solo il piano grafico e non si visualizza l'XML per vedere se è stato suggerito più di un indice mancante. Quello mostrato per primo nel piano grafico non è necessariamente quello con il maggior impatto sulla query.

4) Ho anche incontrato molti esempi di nuovi indici suggeriti quando si modifica l'indice esistente. Vedi le altre risposte qui riguardo a questo punto, sono esatte, non c'è bisogno che io elabori ulteriormente.

Uso i suggerimenti di indice mancanti solo come punto di partenza quando lavoro con una query / ambiente non familiare per vedere dove cercare più in profondità. Ho ottenuto risultati migliori osservando gli operatori nel piano (principalmente le ricerche / scansioni / join) e controllando la descrizione comandi o la finestra delle proprietà per vedere quali colonne sono coinvolte e usando quello per determinare i candidati all'indice per testare il miglioramento.

Ci sono molte ragioni, principalmente - sapendo come funzionano e archiviati gli indici - creerai sempre un indice migliore, o almeno - non peggio, dei suggerimenti di SSMS