Se si dispone di una tabella con un indice cluster sulla chiave primaria (int), è ridondante e errato avere uno (o più) indici non in cluster che includono quella colonna chiave primaria come una delle colonne nella non- indice cluster?È brutto avere un indice non cluster che contiene la chiave primaria dall'indice cluster?
In realtà ci potrebbero essere validi motivi per creare un indice non cluster identico con quello con cluster. Il motivo è che gli indici raggruppati trasportano il bagaglio dei dati di riga e questo può rendere la densità di riga molto scarsa. Vale a dire. puoi avere 2-3 righe per pagina a causa di campi ampi che non sono nella chiave del cluster, ma la chiave dell'indice cluster è solo, diciamo, 20 byte. Avere un indice non cluster su esattamente la stessa chiave (s) e ordine come l'indice cluster darebbe una densità di 2-3 centinaia di chiavi per pagina. Molte query aggregate tipiche per un carico di lavoro OLAP/BI possono essere risolte in modo più efficiente dall'indice non cluster, semplicemente perché riduce l'I/O di centinaia di volte.
Come per gli indici non in cluster che contengono parti della chiave in cluster o anche le stesse chiavi ma in ordine diverso, tutte le scommesse sono disattivate in quanto potrebbero ovviamente essere utilizzate per una moltitudine di query.
Quindi la risposta alla tua domanda è: Depende.
Per una risposta più precisa, è necessario condividere lo schema esatto delle tabelle e le query esatte in questione.
Non c'è una risposta al 100%, ma la risposta è quasi definitiva.
Gli altri indici servono per facilitare l'unione e l'ordinamento (in generale). Dato che la chiave primaria è già indicizzata, se l'ottimizzatore può partecipare in base al fatto che lo utilizzerà.
Se è necessario un altro indice da una prospettiva di join/ordinamento, quale ulteriore aiuto fornisce il PK nel mix di indici? Se prima non poteva unirsi in base al PK, non lo farà ora. E non aiuta davvero nessuno con l'ordinamento.
Sì, in genere non è necessario, poiché le colonne dell'indice cluster sono già state aggiunte a ciascuna voce di indice nell'indice non in cluster.
Perché? Il valore della chiave cluster è ciò che consente realmente a SQL Server di "trovare" una riga di dati - è il "puntatore" ai dati effettivi - quindi in modo ovvio, deve essere memorizzato nell'indice non in cluster. Se hai cercato "Smith, John" e hai bisogno di saperne di più su questa persona, devi andare ai dati effettivi -> e ciò avviene includendo il valore della chiave di clustering nel nodo indice del non indice ristretto.
Il valore della chiave in cluster è già presente, quindi in genere è ridondante e non necessario aggiungere nuovamente tale valore, in modo esplicito, all'indice non in cluster. È male in quanto semplicemente spreca spazio senza darti alcun vantaggio.
Sono con Remus su questo - un indice cluster non è realmente un indice - ti dice come i dati sono organizzati nelle pagine. (Nel tuo caso, è anche la chiave primaria, ma non è necessario che sia la stessa cosa). Gli indici non in cluster includono le informazioni sul locatore di riga, quindi sì, è ridondante.
Ma se un indice non cluster viene coprendoe la riga di dati segnalibro non ha bisogno di essere utilizzato, può essere usato un molto modo più efficiente rispetto l'indice cluster, e l'efficienza aumenta all'aumentare del rapporto tra la dimensione della riga di dati e la dimensione dell'indice non clusterizzato.
Ho scoperto che se si ha una buona padronanza dei percorsi di accesso nel carico di lavoro delle query, a volte è possibile utilizzare alcuni indici di copertura non raggruppati in modo selettivo per eliminare completamente le scelte di clustering: tabella heap, un PK, e alcuni buoni indici non in cluster, e il gioco è fatto.