Comportamento dei dati negli indici in base al fattore di riempimento


14

Supponiamo che tu abbia un database in cui il fattore di riempimento predefinito è 20. Ogni volta che vengono inseriti dati, vengono create solo pagine riempite fino al 20%?

Da quanto ho capito, quando i dati vengono inseriti ci sarà circa il 20% dei dati nelle pagine. Quando i dati vengono aggiornati, tuttavia, si espanderà a oltre il 20% dell'indice, fino a riempirlo e generare una divisione di pagina, giusto?

Risposte:


16

Il fattore di riempimento entra in gioco solo quando viene creato o ricostruito un indice. È la quantità di consumo per l'indice delle pagine a livello foglia che vengono riempite durante queste operazioni. ( vedi la nota sotto per maggiori chiarimenti sui livelli di pagina interessati )

Quando v'è un comando LMD ai dati ( INSERT, UPDATEe / o DELETE), accadrà ai corrispondenti indici interessati. In altre parole, se hai una pagina riempita al 20% e inserisci i dati in quella pagina, la pagina conterrà più del 20% dei dati (diciamo il 35% solo per esempio). Fai un altro inserto, ora la pagina è riempita al 64%. Ricostruire l'indice e le pagine a livello foglia conterranno ora relativamente la percentuale di spazio specificata (o implicitamente il valore predefinito per il server).

( Si noti che quando non si specifica PAD_INDEXdi essere ON, il fattore di riempimento viene applicato solo alle pagine a livello foglia. Ma quando si imposta PAD_INDEX = ON, il fattore di riempimento verrà preso in considerazione per le pagine di livello intermedio dell'indice. L'impostazione predefinita èOFF )

Il motivo per regolare il fattore di riempimento (anziché utilizzare il valore predefinito 100/0) è quello di ridurre al minimo le divisioni di pagina durante l'inserimento o l'aggiornamento dei dati. Ma tieni a mente, niente è gratis. Più basso è il fattore di riempimento, più dati occupano normalmente spazio. Se mantieni uno spazio di pagina libero dell'80% per i tuoi indici, consumeranno una quantità relativamente maggiore di spazio su disco, il che può portare a più letture.

Da quanto ho capito, quando i dati vengono inseriti ci sarà circa il 20% dei dati nelle pagine. Quando i dati vengono aggiornati, tuttavia, si espanderà a oltre il 20% dell'indice, fino a riempirlo e generare una divisione di pagina, giusto?

Quando i dati vengono inseriti, verranno inseriti negli indici appropriati nella pagina appropriata. Ciò potrebbe e molto probabilmente farebbe sì che il consumo della pagina sia superiore al fattore di riempimento.

Una divisione di pagina avverrà quando verranno aggiunti nuovi dati a una pagina di indice completa. SQL Server quindi dividerà la pagina e posizionerà approssimativamente metà dei dati dalla pagina intera in una nuova pagina. Ancora una volta, il fattore di riempimento non entra in gioco qui.

Un motivo legittimo per ridurre il fattore di riempimento sarebbe ridurre al minimo le divisioni di pagina, riducendo così al minimo la frammentazione della pagina di indice.


3
Riduce inoltre al minimo le operazioni di I / O necessarie per espandere o allocare spazio.
JNK,

OK, quindi mi sbagliavo su come funzionava il comportamento. Grazie per una risposta così dettagliata!
DForck42,

1
@ DForck42 Nessun problema, felice di aiutarti.
Thomas Stringer,

Possiamo riassumere questo per dire che l'impostazione di un fattore di riempimento basso tenderà a rallentare le letture (più pagine) ma accelerare gli inserimenti (meno divisioni)?
Jon of All Trades,

2
@Jon: con indice di fillfactor elevato frammento e letture rallentano. Per ogni indice esiste un fattore di riempimento ottimale: sopra e sotto, le scritture e le letture lente. L'ottimalità dipende dai modelli di utilizzo (quanti inserti al giorno), dai modelli di manutenzione (con che frequenza viene ricostruita), dai dati (quanto unica è la chiave). Gli indici non univoci tendono a richiedere più spazio libero (fattore di riempimento inferiore).
wqw,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.