Colonna inclusa contro indice filtrato

Attualmente lavoriamo con la tabella denominata tb_tranfers . Questa tabella ha 40 milioni di righe e ha una dimensione di ~ 26 GB (11 GB di dati, indici di 15 GB).

Dal 10 al 15% delle righe sono file con eliminazione graduale ( DeletedDate non è null). L'applicazione utilizza solo le righe in cui DeletedDate è null. Tutte le query a questa tabella includeranno una clausola in tal senso.

Ci sono 15 indici in questa tabella. L'indice DMV mancante contiene suggerimenti per creare indici con DeletedDate come colonna inclusa.

Sarebbe utile utilizzare un indice filtrato WHERE DeleteDdate IS NULLsu tutti e 11 gli indici non cluster? O sarebbe meglio avere la colonna DeletedDate come colonna inclusa?

Sì, CREATE INDEX ... ON ... WHERE DeletedDate IS NULLsarebbe utile modificare tutti gli 11 indici NC per essere indici filtrati ( ). In questo modo ottieni due vantaggi:

• Query Optimizer saprà che qualsiasi riga proveniente da questi indici già non soddisfare i vostri filtri di query su DeletedDate, quindi non avrà di ricercare l'indice cluster al doppio controllo del DeletedDate
• Tutti gli indici NC avranno dimensioni inferiori del 10-15%, richiedendo meno memoria e meno operazioni di I / O per la ricerca.

Il compromesso è che qualsiasi query che si occupa delle righe cancellate soft (e ci deve essere qualche query, altrimenti perché esistono le righe?) Non sarà in grado di usare questi indici NC.

Se usi SEMPRE il DeletedDate IS NULLfiltro nelle tue query, sì, probabilmente vedrai un aumento significativo delle prestazioni aggiungendo il filtro.

Sono molte meno le pagine che il motore controlla per trovare le righe pertinenti, il che significa meno IO (e più velocità).

Aggiungerlo come INCLUDEDcampo sarebbe inutile . Dato che lo includi sempre nel filtro (ma probabilmente non lo aggiungi mai all'elenco SELECT), a quel campo non verrebbe mai fatto riferimento se lo aggiungi come INCLUDE.

Poiché l'85-90% delle righe ha DeletedDate sono NULL, è improbabile che la selettività di un indice costituito solo da DeletedDate sia sufficiente affinché SQL utilizzi questo indice. Tuttavia, utilizzato insieme ad altre colonne più selettive, l'aggiunta di DeletedDate agli indici esistenti dovrebbe dare qualche vantaggio se aumenta la selettività complessiva dell'indice.

Come dice JNK, DeletedDate sarebbe di scarsa utilità nel coprire gli indici se non lo si utilizza nella clausola SELECT.

Dato che esiste già più spazio di archiviazione per gli indici che per i dati, è possibile che si desideri verificare la presenza di ridondanza nei 15 indici NC esistenti.