Indicizzazione di un database

Perché, in sostanza, un indice è una tabella aggiuntiva, in cui la chiave primaria è il campo che stai indicizzando e l'unico contenuto è la chiave primaria della tabella principale. Quindi ogni aggiornamento deve essere replicato in ogni indice che utilizza il campo che aggiorni.

Questo è particolarmente evidente su Inserts. Immagina se ogni inserto che hai fatto a un tavolo dovesse essere replicato su altri 20 tavoli. Sarà dolorosamente lento.

Si noti che questo peggiora ulteriormente con gli indici composti, in cluster e full-text, ma non voglio complicare ulteriormente il problema.

Gli indici sono fondamentalmente strutture dati aggiuntive che devono essere costruite e archiviate. Costruire inde sprechi La potenza della CPU (durante le operazioni di scrittura) e la memorizzazione spreca la capacità del disco.

Perché vorresti creare e memorizzare indici che non usi mai?

Inserisci gli indici solo quando necessario. Come regola generale, quando sto sviluppando uno schema di database, ogni tabella riceve un indice cluster con chiave primaria PK da cui partire. Questo sarà l'identificativo univoco per i dati in quella tabella. In può essere su 1 colonna o molti.

Dopodiché, di solito aggiungo solo indici univoci non raggruppati sulle colonne su cui voglio forzare l'unicità.

Questo è lo schema di base. Man mano che l'applicazione viene sviluppata e matura, aggiungiamo gli indici in base alle esigenze in base ai problemi di rendimento e al modo in cui stiamo interrogando i dati.

Ogni indice aggiunto aumenta lo spazio utilizzato e aggiunge ulteriore manutenzione. Quindi scegli saggiamente gli indici.

Il punto di forza degli indici è che sono 1) una struttura dati che può essere rapidamente ricercata e 2) più compatta rispetto alle tabelle effettive, consentendo a più indici di adattarsi alla memoria invece di essere impaginati su disco.

Se hai un indice su ogni colonna, allora gli indici stessi occuperanno più spazio della tabella che rappresentano. Se il database usa davvero tutti gli indici, richiederà più tempo solo per scambiarli dentro e fuori dalla memoria. Inoltre, ogni indice deve essere aggiornato su un inerte, aggiornamento o eliminazione.

Oltre a ciò, gli indici su una singola colonna non sono nemmeno il meglio che puoi fare. La maggior parte dei database relazionali in realtà consente un indice su più colonne e l'ordine di queste colonne è importante. Ad esempio, se voglio cercare un database per tutte le persone che sono andate a Duke da classi tra il 1980 e il 1984, allora quello che voglio è un indice su (School, ClassYear). La query non sarebbe in grado di utilizzare un indice con le stesse colonne, ma invertito.

Quindi per creare ogni indice possibile, ce ne sono almeno n! modi per disporre le colonne in un indice. Con solo 5 colonne, ci sono 120 possibili indici.

Poiché ci sono così tanti possibili indici, devi davvero determinare quali indici sono utili per la tua applicazione e crearne solo.

Creare un indice per ogni colonna di una tabella è solitamente uno spreco di spazio e, come altri hanno già detto, può rallentare le operazioni di inserimento / aggiornamento. Un indice viene utilizzato per accelerare le query. Ti consiglio di aggiungere un indice a una colonna solo se noti prestazioni scadenti quando esegui query per i valori in quella colonna.

Alcuni database potrebbero richiedere un indice per la chiave primaria di una tabella in modo che tu possa non avere una scelta a riguardo. Inoltre, se disponi di colonne di testo molto grandi, esistono tecnologie specifiche progettate per la ricerca e l'indice di testo completo, ma non sempre gli stessi tipi di indice che utilizzerai per una piccola colonna numerica.