Base de datos SQL Server con PK GUID en clúster: ¿cambiar de índice agrupado o cambiar a GUID secuenciales (comb)?

Question

Tenemos una base de datos en la que todos los PK son GUID, y la mayoría de los PK son también el índice agrupado de la tabla. Sabemos que esto es malo (debido a la naturaleza aleatoria de los GUID). Entonces, parece que hay básicamente dos opciones aquí (excepto arrojar GUIDs como PK en conjunto, lo que no podemos hacer (al menos no en este momento)).

• Podríamos cambiar el algoritmo de generación GUID a, p. Ej. el que utiliza NHibernate, como se detalla en this post, o
• , para las tablas que son más utilizadas, podemos cambiar a un índice agrupado diferente, p. una columna de IDENTIDAD, y mantener los GUID "aleatorios" como PK.

¿Es posible dar alguna recomendación general en tal escenario?

La aplicación en cuestión tiene más de 500 tablas, la más grande actualmente en alrededor de 1,5 millones de filas, algunas tablas alrededor de 500 000 filas, y el resto significativamente más bajo (la mayoría de ellos muy por debajo de 10K).

Además, la aplicación ya está instalada en varios sitios de clientes, por lo que debemos tener en cuenta los posibles efectos negativos para los clientes existentes.

Gracias!

Answer 1

Si puedes cambiar tu generación de guid a una generación de guid secuencial fácilmente, entonces esa es probablemente su opción de ganar rápido. El guid secuencial detendrá la fragmentación en la tabla mientras permanece como su índice agrupado. Sin embargo, la desventaja principal con una guía secuencial es que se vuelven adivinables, lo que a menudo no se desea y la razón por la que se usan las guías en primer lugar.

Si baja por la ruta Identity para su clave principal agrupada y luego solo un índice en su columna guid, entonces todavía obtendrá mucha fragmentación en su índice GUID. Sin embargo, el hecho de que la mesa ya no se fragmente será una gran ganancia.

Finalmente, sé que dijiste que no puedes hacer esto por ahora, pero, si no NECESITAS usar las guías como índice, entonces eliminas todos estos problemas.

Answer 2

Mi opinión es clara: use una INT IDENTIDAD para su clave de agrupamiento. Eso es, con mucho, la clave de agrupación mejor, más óptimo, debido a su:

• pequeña
• estable (nunca debería cambiar)
• únicas
• cada vez mayores de GUID

secuenciales son definitivamente una mucho mejor que los GUID aleatorios regulares, pero todavía hay cuatro veces más grande que un INT (16 vs 4 byte) y esto será un factor si tienes muchas filas en tu tabla, y muchos índices no agrupados en esa tabla, también . La clave de clúster se agrega a todos y cada uno de los índices no agrupados, por lo que aumenta significativamente el efecto negativo de tener 16 vs 4 bytes de tamaño. Más bytes significa más páginas en el disco y en la RAM de SQL Server y, por lo tanto, más E/S de disco y más trabajo para SQL Server.

Definitivamente puede mantener el GUID como la clave principal, en su caso, pero en ese caso, le recomiendo agregar una INT IDENTIDAD por separado a esa tabla y hacer que INT sea la clave del clúster. Lo he hecho yo mismo con varias tablas grandes, y los resultados son asombrosos: la fragmentación de la tabla ha bajado de 99 y más por ciento a un pequeño porcentaje, y el rendimiento es mucho mejor.

Salida excelente serie de Kimberly Tripp sobre por qué de GUID son malas como las claves de clúster de SQL Server aquí:

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues...
• Ever-increasing clustering key - the Clustered Index Debate..........again!

Marc