Raggruppa l'indice sulla colonna datetime sempre crescente sulla tabella di registrazione?

Question

Io non sono un DBA ("! Good", ti verrà pensando in un momento.)

Ho una tabella dei dati di registrazione con queste caratteristiche e modelli di utilizzo:

• Una colonna datetime per la memorizzazione di timestamp di registro il cui valore è sempre crescente e principalmente (ma solo per lo più) unico
• Inserimenti frequenti (ad esempio, una dozzina di minuti), solo alla fine dell'intervallo di data/ora (nuovi dati registrati
• Elimina raramente, alla rinfusa, fr om il inizio del campo timestamp (vecchi dati che vengono cancellati)
• Nessun aggiornamento a tutti i
• seleziona frequenti-ish che utilizzano la colonna timestamp come criterio primario, insieme con criteri secondari su altre colonne
• Seleziona infrequenti utilizzando altre colonne come i criteri (e non tra cui la colonna timestamp)
• Una buona quantità di dati, ma in nessun posto vicino abbastanza che mi preoccupa molto di spazio di archiviazione

Inoltre, attualmente esiste una finestra di manutenzione giornaliera durante la quale è possibile eseguire l'ottimizzazione della tabella.

Francamente non mi aspetto che questa tabella sfidi il server su cui si accederà anche se indicizzo male un po ', ma tuttavia mi è sembrata una buona opportunità per chiedere un input sugli indici cluster di SQL Server.

So che gli indici cluster determinano la memorizzazione dei dati della tabella effettiva (i dati sono memorizzati nei nodi foglia dell'indice stesso) e che gli indici non in cluster sono indicatori separati nei dati. Quindi, in termini di query, un indice cluster sarà più veloce di un indice non in cluster - una volta che abbiamo trovato il valore dell'indice, i dati sono proprio lì. Ci sono costi per l'inserimento e l'eliminazione (e ovviamente un aggiornamento che modifica il valore della colonna dell'indice clustered sarebbe particolarmente costoso).

Ma ho letto in this answer che elimina gli spazi vuoti che non vengono ripuliti fino a/a meno che l'indice non venga ricostruito.

Tutto questo mi fa pensare che avrei dovuto:

• Mettere un indice cluster sulla colonna timestamp con un fattore di riempimento 100%
• indici non cluster mettere su qualsiasi altra colonna che potrebbe essere utilizzato come criterio in una query che non coinvolge anche la colonna in cluster (che può essere qualsiasi di esse nel mio caso)
• Pianificare le eliminazioni di massa che si verificano durante l'intervallo di manutenzione giornaliera
• Pianificare una ricostruzione del cluster indice che si verifica immediatamente dopo il bulk de Lete
• rilassarsi e di più

Am I di base selvaggiamente fuori là? Devo ricostruire frequentemente l'indice in questo modo per evitare un sacco di spazio sprecato? Ci sono altre cose ovvie (a un DBA) che dovrei fare?

Grazie in anticipo.

Answer 1

Concordo con l'inserimento dell'indice cluster sulla colonna timestamp. La mia interrogazione sarebbe sul fillfactor: il 100% offre le migliori prestazioni di lettura a scapito delle prestazioni di scrittura. potresti essere ferito dalla divisione delle pagine. La scelta di un fattore di riempimento inferiore ritarderà la divisione delle pagine a scapito delle prestazioni di lettura, pertanto è un ottimo bilanciamento per ottenere il meglio per la propria situazione.

Dopo che il bulk ha eliminato, vale la pena ricostruire gli indici e aggiornare le statistiche. Ciò non solo mantiene le prestazioni ma reimposta anche gli indici sul fillfactor specificato.

Infine, sì inserire indici non cluster su altre colonne appropriate, ma solo quelli che sono molto selezionati, ad esempio non campi bit. Ma ricorda più indici, più questo influisce sulle prestazioni di scrittura

Answer 2

Ci sono due modi "best practice" per indicizzare un alto traffico tabella di registrazione:

1. una colonna integer identità come chiave primaria Colum
2. un uniqueidentifier cluster come chiave primaria, con DEFAULT NEWSEQUENTIALID()

Entrambi i metodi consentono a SQL Server di espandere la tabella in modo efficiente, poiché sa che l'albero dell'indice crescerà in una determinata direzione.

Non aggiungerei altri indici sulla tabella o pianificare le ricostruzioni dell'indice, a meno che non ci sia un problema di prestazioni specifico.

Answer 3

La risposta ovvia dipende da come lo si interroga. Il punto dell'indice è di ridurre la quantità di confronti quando si selezionano i dati. L'indice cluster aiuta quando si considerano i dati che verranno caricati insieme e il fattore di blocco della memoria (è possibile caricare un gruppo di dati in un blocco di 64k con una lettura). Se includi un ID e un datetime come chiave primaria, ma non li utilizzi nei criteri di selezione, non faranno altro che ostacolare le tue prestazioni. Questo è il motivo per cui le persone di solito rilasciano indici su inserimenti di massa prima di caricare i dati.

Answer 4

Contrariamente a quanto molti credono, avere un buon indice cluster su un tavolo può effettivamente rendere più veloci le operazioni come INSERT - sì, più veloce!

Scopri il blog post seminale The Clustered Index Debate Continues.... di Kimberly Tripp - l'ultima regina dell'indicizzazione.

Accenna (circa a metà di questo articolo):

inserti sono più veloci in un cluster tavolo (ma solo nel "giusto" tabella cluster) che, rispetto a un cumulo . Il problema principale qui è che le ricerche in IAM/PFS per determinare la posizione di inserimento in un heap sono più lenta in una tabella cluster (dove è nota la posizione di inserimento, definita dalla chiave cluster). Gli inserti sono più veloci se inseriti in una tabella dove l'ordine è definito (CL) e dove quell'ordine è in costante aumento.

Il punto cruciale è: solo con il diritto indice cluster si sarà in grado di raccogliere i frutti - quando un indice cluster è unico, stretto, stabile e in modo ottimale sempre crescente. Questo è meglio servito con una colonna INT IDENTITY.

Kimberly Tripp ha anche un grande articolo su come scegliere il miglior chiave di clustering possibile per le tabelle, e quali criteri dovrebbe compiere - vedere il suo post intitolato Ever-increasing clustering key - the Clustered Index Debate..........again!

Se si dispone di una colonna di - per esempio una chiave primaria surrogata: usa quella per la tua chiave di clustering e dovresti vedere prestazioni molto buone sul tuo tavolo - anche su molti INSERT.