Vacca santa, hai molte domande qui. Analizziamo questo.
D: SQL "sposta" le righe esistenti per mantenere il clustering o consente alla tabella di diventare "frammentata"?
Pensa a un database come a una raccolta di pagine: letterali pezzi di carta disposti sulla tua scrivania. Pensa al dizionario per ora. Se si desidera aggiungere più parole al dizionario, è possibile aggiungerle se le pagine hanno spazio vuoto.
Quando inizi con un dizionario vuoto, questo è relativamente semplice. Ma pensa a un dizionario maturo con migliaia di pagine di carta, tutte piene.
Quando vuoi aggiungere più parole a quel dizionario maturo, è probabile che non ci sarà più spazio sulla pagina. SQL Server "strapperà" una pagina: ci vorrà una pagina nuova di zecca altrove e sposta alcune delle parole su quella nuova pagina. La nuova pagina sarebbe alla fine del dizionario. La buona notizia è che subito dopo quell'azione, ora c'è una pagina semivuota alla fine del dizionario e anche al centro, entrambe con spazio per aggiungere parole.
Se ti capita di aggiungerli in quell'ordine, cioè. (Ecco perché il modo in cui carichi i dati diventa sempre più importante.)
Ciò potrebbe causare un notevole calo delle prestazioni se l'importazione viene eseguita una riga alla volta?
Dimentica l'indice per un secondo - l'aggiunta di dati una riga alla volta è semplicemente inefficiente indipendentemente dalla struttura dell'indicizzazione. SQL Server è un sistema basato su set: ogni volta che puoi lavorare in set, probabilmente dovresti.
Cosa succede quando eseguo una query sui dati?
Non me l'hai chiesto, ma te lo sto chiedendo, hahaha.
Ripensa alle conseguenze dei nostri inserti. Ora abbiamo un dizionario che è per lo più ordinato, ma quando arrivi ad alcuni punti del dizionario, dovrai saltare sul retro per leggere da poche altre pagine. Se queste pagine sono tutte memorizzate nella cache (RAM, pool di buffer, ecc.), L'overhead non sarà così grande. La maggior parte dell'accesso alla memoria è casuale, non è come se SQL Server memorizzasse il dizionario in ordine.
D'altra parte, se è necessario recuperare i dati dai dischi rigidi magnetici convenzionali (ruggine che gira), è possibile ottenere un vantaggio in termini di prestazioni se i dati vengono archiviati in ordine. Il vero obiettivo di progettazione qui, tuttavia, è quello di ottenere i dati dalla RAM invece di ottenerli dalle unità. La differenza tra i dati deframmentati su disco rispetto ai dati frammentati su disco non è affatto significativa quanto la differenza tra ottenerli dal disco e ottenerli dalla RAM .
Dovrei piuttosto non preoccuparmi dell'ordinamento delle righe e aggiungere semplicemente una colonna di identità come chiave primaria e un indice nella colonna Data per aiutarmi con le mie query?
Bingo: questa è la differenza tra la progettazione fisica del database e la progettazione logica del database. I programmatori devono preoccuparsi molto della progettazione fisica del database inizialmente, ma finché il database è sotto, diciamo, con dimensioni di 100 GB, è possibile correggere la progettazione logica in post, per così dire. Metti un campo identità lì per cominciare, raggruppalo su di esso e poi, dopo essere stato attivo per alcuni mesi, rivisita il design dell'indice per massimizzare le prestazioni.
Ora, detto questo, una volta che hai sperimentato questo tipo di processo decisionale, allora sarai meglio attrezzato per indovinare gli indici fin dall'inizio. Anche così, di solito non ho nemmeno pensato molto alla progettazione dell'indice inizialmente. Gli utenti non sembrano mai interrogare i dati come mi sarei aspettato.