Utilizzo di GUID nelle chiavi primarie/Indici corretti

Question

Sono abbastanza esperto in SQL server performace ma devo costantemente discuterne l'idea che i GUID debbano essere utilizzati come tipo predefinito per Clusterd Primary Keys.

Supponendo che la tabella abbia una quantità di inserti al giorno piuttosto bassa (5000 +/- righe/giorno), che tipo di problemi di esecuzione potremmo riscontrare? In che modo le suddivisioni di pagina influenzano le nostre prestazioni di ricerca? Con quale frequenza devo reindicizzare (o devo deframmentare)? Cosa devo impostare i fattori di riempimento su (100, 90, 80, ect)?

E se inserissi 1.000.000 di file al giorno?

Mi scuso per tutte le domande, ma sto cercando di ottenere un backup per non utilizzare GUID come predefinito per PK. Sono comunque completamente aperto all'idea che la mia mente sia cambiata dalla conoscenza eccessiva della base di utenti di StackOverflow.

Answer 1

Se stai facendo qualsiasi tipo di volume, il GUID sono estremamente male come una cattiva PK a meno di utilizzare sequential GUIDs, per i motivi precisi che descrivi. Page fragmentation is severe:

    Average     Average 
       Fragmentation Fragment Fragment Page  Average 
Type    in Percent  Count  Size  Count Space Used 

id    4.35   7   16.43  115  99.89 
newidguid  98.77   162   1   162  70.90 
newsequentualid 4.35   7   16.43  115  99.89 

E come this comparison tra GUID e interi mostra:

Test1 causato un enorme quantità di divisioni di pagina, e aveva una densità di scansione attorno 12% quando mi sono imbattuto un DBCC SHOWCONTIG dopo gli inserti erano stati completati. La tabella Test2 aveva una densità di scansione intorno al 98%

Se il volume è molto basso, tuttavia, non importa più di tanto.

Se si ha realmente bisogno di un ID univoco globale ma con un volume elevato (e non è possibile utilizzare ID sequenziali), inserire i GUID in una colonna indicizzata.

Answer 2

Inconvenienti di utilizzare GUID come chiave primaria:

• n ordinazione significativo, mezzi indicizzatori non dà incremento delle prestazioni come fa con un numero intero.
• Dimensioni di un GUID 16 byte, contro 2, 4 o 8 byte per un numero intero.
• Molto difficile da ricordare per gli umani, quindi non valido come riferimento.

Vantaggi:

• accettano non indovinare chiavi primarie che possono quindi essere meno pericoloso quando viene visualizzata in una stringa di query pagina Web o nell'applicazione.
• Utile in database che non forniscono un tipo di dati di incremento automatico o identità.
• Utile quando è necessario unire i dati tra due fonti di dati eterogenee su piattaforme o ambienti.

Ho pensato che decidere se utilizzare GUID fosse piuttosto semplice, ma forse non sono a conoscenza di altri problemi.

Answer 3

Con inserti così bassi al giorno, dubito che la divisione delle pagine dovrebbe essere un fattore significativo. La vera domanda è in che modo 5.000 si confronta con il conteggio delle righe esistente, in quanto questa sarebbe l'informazione principale necessaria per decidere su un fattore di riempimento iniziale appropriato per interrompere le divisioni.

Detto questo, personalmente non sono un grande fan dei GUID. Capisco che possono servire bene in alcuni contesti, ma in molti casi sono solo "nel modo" [di efficienza, di facilità d'uso, di ...]

Trovo le seguenti domande utili per restringere decidere se utilizzare o meno GUID.

• Il PK sarà condiviso/pubblicato? (Cioè verrà utilizzato oltre il suo uso interno in SQL, avranno applicazioni bisogno di queste chiavi in ​​un modo un po 'persistente? Saranno utenti in qualche modo vedere queste chiavi?
• Può la PK essere usato per aiutare unire diverse fonti di dati?
• La tabella ha un primario - composto in modo sintetico dalle colonne nei dati? Qual è la dimensione di questa possibile questa chiave
• Come si ordinano le chiavi primarie?Se composito, le prime colonne sono selettive?

Answer 4

Utilizzare un guid (a meno che non sia un GUID sequenziale) poiché un indice cluster uccide le prestazioni dell'inserto. Poiché il layout della tabella fisica è allineato in base all'indice cluster, l'utilizzo di un guid che ha un ordine sequenziale casuale causerà una frammentazione seria della tabella. Se si desidera utilizzare un guid come indice PK/Cluster, deve essere un guid sequenziale che utilizza la funzione newsequentialid() in sql server. Ciò garantirà che i guids generati vengano ordinati sequenzialmente e impediscano la frammentazione.