Indicizzazione di singoli campi di chiavi composite di SQL Server

Sto aggiornando un database Jet a SQL Server Express 2008 R2 e prima di farlo, sto rivalutando lo schema (è stato progettato nel 1997-98 e il ragazzo che progettato (cioè, io) era qualcosa di un deficiente!).Indicizzazione di singoli campi di chiavi composite di SQL Server

La mia domanda riguarda N: N join tabelle con una chiave composita a due colonne. In Jet, i join sulla prima colonna di una chiave composita a due colonne utilizzeranno l'indice composito, ma i join sulla seconda colonna non lo faranno, quindi in generale, nei database Jet con tabelle N: N di grandi dimensioni con un numero ragionevolmente elevato di record , oltre all'indice composito aggiungo un secondo indice non univoco sulla seconda colonna.

È una buona idea in SQL Server?

(forse non è una buona idea in Jet?)

fonte

2010-08-31 David-W-Fenton

Le stesse regole si applicano in SQL Server. Se hai un indice su (ColumnA, ColumnB) una query solo su ColumnA o ColumnA e ColumnB insieme possono usare l'indice, ma una query solo su ColumnB non può. Se è necessario unirsi solo su ColumnB, è necessario creare l'indice.

fonte

2010-08-31 20:55:41

Qualsiasi svantaggio, a parte gli evidenti problemi di manutenzione dell'indice? –

Considerazioni sullo spazio per la memorizzazione dell'indice. Overhead aggiuntivo sulle operazioni di inserimento/aggiornamento/cancellazione. Considera anche la cardinalità di ColumnB. Se è bassa cardinalità (pochi valori unici), l'indice potrebbe non essere di aiuto. –

In generale, la mia ColumnB ha una cardinalità inferiore a ColumnA. Riuscirebbe a invertirli e ad aggiungere l'indice non duplicato sulla colonna con la cardinalità più elevata sarebbe più efficiente? –

Se si dispone di un indice composito su colonne (A,B) senza ricerca, scorrimento gamma, tipo o il funzionamento aggregato può essere utilizzato per le espressioni che contengono soloB. Questo è vero per SQL Server, proprio come era vero per i driver Jet (Red) (e penso anche per Jet Blue). Alcuni altri motori potrebbero usarlo in una cosiddetta operazione skip scan.

Quindi la risposta è che sono necessari indici separati su (B) da solo.

fonte

2010-08-31 20:58:38

Se la tabella viene usata principalmente con join su entrambe le colonne, aiuterà SELEZIONARE tanto quanto sarebbe in un SELECT usando solo la 2a colonna in un join? Il mio pensiero è che l'ottimizzatore selezionerà prima sul lato che ha un indice e quindi avrà meno da fare sull'altro lato, quindi con entrambi i join sarà più efficiente che con il join solo sul lato non indicizzato. Dal momento che non utilizzo quasi mai tabelle di join senza entrambi i join, forse non sarà di grande aiuto? –

Se il join è su entrambe le colonne, l'indice su '(B)' da solo verrà probabilmente ignorato. Ma se cerchi/unisci principalmente su 'A' e' B', * a volte * su 'B' da solo ma * mai * su' A' solo allora puoi prendere in considerazione la possibilità di cambiare l'indice in '(B, A)' anziché. –

Come regola generale, l'ordine delle colonne in un indice dovrebbe essere in ordine crescente di selettività, a meno che non sia necessario indirizzare specifici ORDER BY.Se si inseriscono colonne a bassa selettività sul lato più a sinistra, le query aggregate e di grandi dimensioni continuano a utilizzare l'indice, ma si tenga presente che anche una colonna a bassa selettività cadrà rapidamente nella trappola del punto di svolta: http://www.sqlskills.com/BLOGS /KIMBERLY/category/The-Tipping-Point.aspx. Avere una colonna a bassa selettività (come 'Tipo') in alto a sinistra ha più senso sugli indici cluster perché gli indici cluster sono sempre a copertura, non hanno un punto di svolta. –

Per aiutarvi di più, solo un consiglio, in SQL server utilizzando lo studio di Managment è possibile valutare il rendimento di "Visualizza piano di esecuzione stimato". Ha mostrato come funzionano gli indici e join.

Inoltre è possibile utilizzare DTA (Ottimizzazione guidata motore di database) per ulteriori informazioni e ottimizzazione.

fonte

2010-08-31 21:09:43

Indicizzazione di singoli campi di chiavi composite di SQL Server

risposta

Problemi correlati