SQL Server creazione di più gli indici non cluster per una colonna vs avere più colonne in un solo indice

Question

Supponiamo che io abbia seguente tabella

• UserID (Identità) PK
• UserName - unico non nullo
• UserEmail - unico nel suo genere non null

Cosa è consigliato per la migliore prestazione?

• creazione di indice non cluster per UserName e UserEmail separatamente

O

• Solo una comprese sia le colonne

Si prega di fare la parte si pensieri perché uno è preferibile rispetto altro.

Answer 1

Un altro punto importante da considerare è questo: un indice composto (composto da più colonne) verrà utilizzato solo se si fa riferimento alle colonne n più a sinistra (ad esempio in un WHERE clausola)

Quindi, se si dispone di un indice composto singolo su

(UserID, UserName, UserEmail) 

allora questo indice potrebbe essere utilizzato nei seguenti scenari:

• quando siete alla ricerca di UserID sola (utilizzando solo la colonna più a sinistra 1 - UserID)
• quando sei alla ricerca di UserID e UserName (utilizzando i 2 più a sinistra colonne)
• quando siete alla ricerca di tutte le tre colonne

Ma questo unico indice composto sarà mai essere in grado di essere utilizzato per le ricerche su

• solo UserName - è la seconda colonna nell'indice e quindi questo indice non può mai essere utilizzato
• solo UserEmail - e 'la terza colonna nell'indice e quindi questo indice non può mai essere utilizzato

Ju st ricordo che - solo perché una colonna fa parte di un indice non significa necessariamente che la ricerca su quella singola colonna sarà supportata e accelerata da quell'indice!

Quindi, se i vostri modelli di utilizzo e l'applicazione realmente bisogno per cercare UserName e/o UserEmail da solo (senza fornire altri valori di ricerca), allora si necessario creare indici separati su queste colonne - solo un singolo composto lo farà non hanno alcun vantaggio.

Answer 2

Il modo migliore per definire gli indici dipende interamente da come verrà utilizzata la tabella. Non esiste un modo sensato di scegliere gli indici semplicemente osservando la definizione della tabella.

Se il codice cerca nella tabella con nome utente o si unisce alla tabella con un'altra tabella tramite nome utente, sarebbe opportuno definire un indice su tale colonna. Se il tuo codice si unisce alla tabella con un'altra tabella usando due colonne (username e usermail), sarebbe saggio definire l'indice per queste due colonne. Dal momento che tutte le tue colonne sono definite come uniche, non credo che questo accadrà, quindi non avrai bisogno di più indici di colonne su quella tabella.

Potrebbero esserci alcuni consigli aggiuntivi sull'uso di più indici di colonne: più indici di colonne vengono utilizzati anche per filtri che si adattano parzialmente all'indice, ma con condizioni.
Esempio: Se si definisce un indice a due colonne su username e usermail (nell'ordine specificato), si avrà un aumento delle prestazioni nelle ricerche che filtrano attraverso entrambe le colonne (nome utente e usermail). Con questo indice si avranno anche miglioramenti delle prestazioni nei filtri che utilizzano solo il nome utente perché questa è la prima colonna dell'indice, ma non nelle ricerche attraverso usermail, poiché la seconda colonna di un indice non può essere utilizzata da sola.
La regola è: un indice può essere utilizzato per filtrare con colonne di corrispondenza esatta o filtrare con un sottoinsieme di colonne che corrispondono alle successive colonne superiori nella definizione dell'indice.

Answer 3

Si prega di condividere i vostri pensieri perché uno è preferibile rispetto agli altri.

Dipende da ciò che si fa.

Vedere, un indice viene utilizzato solo da sinistra a destra. Quindi, un indesiderato su UserID; UserName è inutile se seleziono il filtro SOLO da UserName.

In generale, vorrei assumere tre indici qui:

• uniuqe Indice, raggruppati in UserID, come chiave primaria.
• Indice univoco su UserName, non in cluster.
• Indice univoco su UserEMail, non in cluster.

Il motivo non è del tutto per le prestazioni, ma:

• sarà necessario il prima come chiave primaria per i rapporti chiave estranei,.
• Hai bisogno degli altri due per gestire correttamente i vincoli univoci - non c'è modo di farlo senza indici.

In aggiunta, è necessario ricercare la flessibilità in base a UserName AND UserEMail, il che significa che non è possibile combinarli solo.

prestazioni entra davvero l'ultima qui -. Per performacne e ragioni di tutti questi indici può contenere tutti i campi aggiuntivi (non come parte dell'indice, ma come colonne incluse Ma in realtà, non c'è altro modo sensato di avere questo tavolo di lavoro, a meno Si aprono più registrazioni per lo stesso utente