Dove posso trovare alcune indicazioni sulle strategie dell'indice?

La maggior parte di noi sarà probabilmente d'accordo sul fatto che l'uso degli indici del database sia buono. Troppi indici e prestazioni possono effettivamente essere degradati.

Come regola generale, quali campi devono essere indicizzati?
Quali campi non devono essere indicizzati?
Quali sono le regole per usare gli indici mentre si raggiunge un equilibrio tra troppi e non abbastanza indici per ottenere miglioramenti delle prestazioni, non degrado?

Corto

Penso che la regola "troppi indici" sia un po 'fuorviante.

Lungo

Dato che il database medio è di circa il 98%, le letture (o superiori) devono essere ottimizzate. Un INSERT è una lettura se esiste un indice univoco, ad esempio. O il WHERE su un aggiornamento. Una volta ho letto che anche un database ad alta intensità di scrittura è ancora 85% di letture.

Quello che hai è un indice di scarsa qualità. Esempi:

• indici cluster ampi (soprattutto SQL Server)
• cluster non monotonico indicizzato
• indici sovrapposti (ad es. cold, coleecold, cole, colf)
• molti indici a colonna singola (anche sovrapposti con indici più utili) che sono inutili per le tue query
• no INCLUDE, non compresi (ad es. tutti gli indici a colonna singola)
• ...

Nota che è abbastanza tipico avere indici molte volte più grandi dei tuoi dati reali anche nei sistemi OLTP.

In generale, inizierei con il

• indice cluster (di solito PK)
• indici univoci (non vincoli, questi non possono essere coperti)
• colonne chiave esterna

Quindi guarderei:

• domande comuni e vedi di cosa ho bisogno. Una query in esecuzione ogni secondo deve essere ottimizzata. Il rapporto di domenica 4am può attendere.
• con SQL Server, i DMV indice mancanti ponderati

Detto questo, ho infranto queste regole per alcuni sistemi dopo aver visto come le cose si sono spostate (10 miliardi di righe dopo) per mettere a punto un sistema. Ma non prenderei mai in considerazione di non indicizzare se non potessi dimostrare perché lo sto facendo.

Dovresti profilare l'utilizzo e il caricamento del database e identificare i colli di bottiglia a causa di indici mancanti o a causa di troppi indici. Quindi devi scegliere l'indice corretto e ciò richiede una buona conoscenza delle specifiche tecniche di indicizzazione del database.

Semplicemente una delle migliori serie di articoli scritti su quali indici scegliere e perché sarebbe di Gail Shaw. Puoi trovare gli articoli facendo clic qui

Alla domanda che fai puoi rispondere in 50 modi diversi. In realtà tutto si riduce ai dati che hai e al modo in cui verranno interrogati. Una regola generale è che dovresti sempre avere un indice cluster su ogni tabella per evitare cumuli. Gli indici cluster dovrebbero in genere essere i più piccoli possibili. Se la tabella ha un indice cluster, tutti i record indice nelle pagine foglia dell'indice non cluster memorizzeranno il valore record dell'indice cluster corrispondente per le ricerche dei segnalibri. Se una tabella è un heap, SQL creerà un identificatore univoco per le ricerche nei segnalibri. Non riesco a ricordare la dimensione che è di 8 o 16 byte. Questo potrebbe finire per essere un tipo di dati molto più grande, quindi dire un INT. Immagina di avere 8 indici non cluster su una tabella heap.

Voglio aggiungere qui che database diversi richiedono strategie diverse. Confrontiamo MySQL con InnoDB e PostgreSQL per esempio.

InnoDB

Le tabelle InnoDB sono fondamentalmente un indice b-tree della chiave primaria che viene esteso per includere le informazioni sulla riga nella voce di indice. Le scansioni dell'ordine fisico non sono supportate e tutte le scansioni avvengono in ordine logico. Ciò significa due cose:

1. Una scansione sequenziale in Innodb genera molti I / O su disco casuali e

2. L'indice della chiave primaria deve essere attraversato indipendentemente dal fatto che si stia utilizzando un indice secondario.

3. Le ricerche di chiavi primarie sono più veloci in questo modello che in qualsiasi altro approccio.

In questo caso è molto importante indicizzare abbastanza campi in tabelle multi-pagina. La regola tipica è indicizzare tutto ciò che si desidera filtrare.

PostgreSQL

PostgreSQL utilizza file heap, una tabella per file (alcune tabelle possono essere molti file) in cui le tuple sono allocate dallo spazio libero di tale heap. Le scansioni dell'ordine fisico sono supportate. Perché una scansione di ordine logico funzioni, è necessario aggiungere un indice.

Le chiavi primarie in PostgreSQL sono fondamentalmente un sottoinsieme di indici univoci in cui nessun valore può essere NULL. I vincoli UNIQUE vengono eseguiti utilizzando indici impliciti e numerosi altri tipi di indice sono supportati con diverse operazioni possibili nell'indice.

Questo significa:

1. Ricerche di chiavi primarie, presupponendo un tablerequire ragionevolmente grande che colpisce un file indice e un file di tabella. Questo è significativamente più lento dell'approccio di MySQL in cui solo l'indice deve essere attraversato e la riga è contenuta nell'indice.

2. Le scansioni dell'ordine fisico funzionano molto meglio, riducendo l'I / O casuale del disco in cui devono essere elaborati numeri significativi di righe.

3. Le scansioni dell'indice secondario funzionano meglio di quelle di MySQL perché è necessario attraversare un solo indice per raggiungere la parte fisica della tabella.

In questo modello, gli indici sono spesso necessari, ma il pianificatore ha più libertà quando usare un indice e le implicazioni del non usarne uno sono spesso meno gravi. Le tabelle sono generalmente più ottimizzate (piuttosto che specializzate nelle ricerche di pkey) e quindi sono richiesti meno indici.

TL; DR

Conosci il tuo RDBMS.

Dalla Guida ai concetti di Oracle 11.2:

• Panoramica degli indici

Dalla guida all'ottimizzazione delle prestazioni 11.2:

• Scelta di colonne ed espressioni da indicizzare
• Utilizzo di indici e cluster

Dalla Guida dell'amministratore 11.2:

• Linee guida per la gestione degli indici

Anche con tutti i link sopra, è necessario guardare a ciò che Kimberly Tripp ha scritto riguardo alla cura, all'alimentazione e all'uso degli indici.

Per cominciare, segui questo link alla raccolta di Kimberly dei suoi post sul blog relativi all'indice. Puoi esplorare argomenti specifici utilizzando i widget "In questa pagina" e "Categorie" sul lato sinistro della finestra del browser.

Ci sono molte informazioni qui, ma non lasciarti scoraggiare.

La pagina Informazioni su Kimberly è qui

Ecco alcune altre risorse che potresti trovare utili se lavori con SQL Server:

• http://www.toadworld.com/platforms/sql-server/w/wiki/9624.indexing.aspx
• http://www.sql-server-performance.com/category/tips/index/
• http://sqlfool.com/summit2010/
• http://sqlfool.com/2011/06/index-defrag-script-v4-1/