Uso de GUID en claves primarias/Índices agrupados

Question

Estoy bastante bien versado en el rendimiento del servidor SQL, pero constantemente tengo que argumentar la idea de que los GUID se utilicen como tipo predeterminado para Clusterd Primary Keys.

Suponiendo que la tabla tiene una cantidad bastante baja de insertos por día (5000 +/- filas/día), ¿con qué tipo de problemas de ejecución podríamos toparnos? ¿Cómo afectarán las divisiones de página a nuestro rendimiento de búsqueda? ¿Con qué frecuencia debo reindexar (o debo desfragmentar)? ¿Qué debo configurar los factores de relleno para (100, 90, 80, ect)?

¿Qué sucede si inserto 1,000,000 de filas por día?

Pido disculpas por todas las preguntas, pero estoy buscando obtener una copia de seguridad para no usar GUID como nuestro valor predeterminado para PK. Sin embargo, estoy completamente dispuesto a que mi mente cambie gracias al conocimiento extenso de la base de usuarios de StackOverflow.

Answer 1

Si está haciendo cualquier tipo de volumen, los GUID son extremadamente malos como PK dañinos a menos que use sequential GUIDs, por las razones exactas que describe. 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 

Y como this comparison entre GUID y enteros muestra:

Prueba1 causado una enorme cantidad de divisiones de página, y tenía una densidad de recorrido alrededor 12% cuando me encontré con un DBCC SHOWCONTIG después las inserciones se habían completado. La tabla Test2 tenía una densidad de escaneo alrededor del 98%

Sin embargo, si su volumen es muy bajo, simplemente no importa demasiado.

Si realmente necesita una ID global única pero tiene un gran volumen (y no puede usar identificadores secuenciales), simplemente coloque los GUID en una columna indexada.

Answer 2

inconvenientes del uso de GUID como clave principal:

• Sin pedido significativa, medios de indexación no da aumento de rendimiento como lo hace con un entero.
• Tamaño de un GUID 16 bytes, frente a 2, 4 u 8 bytes para un entero.
• Muy difícil de recordar para los humanos, por lo que no sirve como identificación de referencia.

Ventajas:

• permitan a los no adivinar las claves primarias, por tanto, que pueden ser menos peligroso cuando se muestra en una cadena de consulta la página web o en la aplicación.
• Útil en Bases de datos que no proporcionan un incremento automático o tipo de datos de identidad.
• Útil cuando necesita unir datos entre dos orígenes de datos dispares en plataformas o entornos.

Pensé que la decisión sobre si usar GUIDs era bastante simple, pero tal vez no tengo conocimiento de otros problemas.

Answer 3

Con una inserción tan baja por día, dudo que la división de la página sea un factor importante. La verdadera pregunta es cómo se compara 5,000 con el recuento de filas existente, ya que esta sería la información principal necesaria para decidir sobre un factor de relleno inicial apropiado para defraudar las divisiones.

Dicho esto, personalmente no soy un gran admirador de los GUID. Entiendo que pueden funcionar bien en algunos contextos, pero en muchos casos simplemente están "en el camino" [de eficiencia, facilidad de uso, de ...]

Me resultan útiles las siguientes preguntas para reducir decidir si se debe usar GUID o no.

• ¿Se compartirán/publicarán las PK? (Es decir, ¿Se utilizará más allá de su uso interno dentro de SQL, serán las aplicaciones que necesite estas teclas de una forma un tanto persistente? ¿Se usuarios de alguna manera ver estas llaves?
• Podría utilizarse el PK para ayudar a fusionar las fuentes de datos dispares?
• ¿La tabla tiene una primaria -posiblemente compuesta- hecha de columna (s) en los datos? ¿Cuál es el tamaño de esta posible esta clave?
• ¿Cómo se clasifican las teclas principales?Si es compuesto, ¿son selectivas las primeras pocas columnas?

Answer 4

Usando un guid (a menos que sea un GUID secuencial) como un índice agrupado va a matar el rendimiento de inserción. Dado que el diseño de la tabla física se alinea según el índice agrupado, usar un guid que tenga un orden de secuencia aleatorio causará una fragmentación seria de la tabla. Si desea utilizar un guid como PK/índice agrupado, debe ser un guid secuencial utilizando la función newsequentialid() en el servidor sql. Esto garantizará que las guías generadas se ordenan secuencialmente y evitan la fragmentación.