Tengo una tabla con un gran número de filas (10K +) y su clave principal es GUID. La clave principal está agrupada. El rendimiento de la consulta es bastante bajo en esta tabla. Por favor, brinde sugerencias para hacerlo eficiente.Mejora del rendimiento de la clave principal GUID de índice de clúster
Es necesario utilizar newsequentialid() en su lugar ver aquí Some Simple Code To Show The Difference Between Newid And Newsequentialid
He leído mucho sobre newsequentialid() pero parece ser una función de SQL. ¿Alguien puede decirme qué hacer si Guid se genera desde Code (C#)? –
-1 ¿Qué tiene que ver esta respuesta con la agrupación física de índices? La persona que hace la pregunta ya ha declarado que tiene 10 K + filas y probablemente no quiere ir y cambiar todas las teclas. – nashwan
Puede probar los GUIDS secuenciales, lo que hará que el índice sea más efectivo. Información here.
Un índice agrupado en GUID no es un buen diseño. La naturaleza misma de GUID es que es aleatorio, mientras que un índice agrupado físicamente ordena los registros por la clave. Las dos cosas están completamente en desacuerdo. ¡Por cada inserción, SQL tiene que reordenar los registros en el disco! Eliminar la agrupación de este índice!
El momento de usar la agrupación es cuando tiene un orden "natural" de los datos: hora insertada, número de cuenta, etc. Para los campos de tiempo, la agrupación es casi gratuita. Para el número de cuenta, puede ser gratuito o barato (cuando los números de cuenta se asignan secuencialmente).
Si bien puede haber formas técnicas en torno al problema de GUID, la mejor idea es comprender cuándo usar el clúster.
+1 para el tono áspero. No hay mucho área gris en esta pregunta. No lo hagas – Droogans
Por favor, evitar la creación de índice agrupado para las columnas de cadena lenghty. GUID tendrá 36 caracteres. Reducirá el rendimiento de la consulta incluso si ha creado como índice agrupado. para una mejor práctica, use columnas de identidad entera.
Guid tiene 16 bytes, no 36 caracteres. –
entero no es un buen diseño para grandes bases de datos – Leonardo
Kimberly Tripp discute este problema para tablas grandes muy bien en su sitio en este enlace: [GUIDs como PRIMARY KEYs y/o la clave de agrupamiento] (http://www.sqlskills.com /BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx). – Graeme
Tiene que analizar su consulta. Solo podemos adivinar por qué sus consultas tienen un mal rendimiento sin ver el plan de ejecución (que puede silenciar fácilmente desde SQL Server u Oracle).
Considerando que un GUID es un valor de 128 bits (si se almacena en bruto), un GUID reduce la densidad de los bloques de datos e índices hasta en un 50% (en el caso del índice de clave principal) así que asegúrese GUID es apropiado.
Pero ese podría no ser el problema, entonces revise el plan de consulta. Podría ser varios otros problemas.
No hay problema con el uso de un GUID como clave principal. Solo asegúrese de que cuando configure el GUID como la clave principal, configure el índice que crea automáticamente para que sea del tipo No agrupado. Mucha gente olvida (o no sabe) hacer esto en SQL Server.
NUNCA utilice un índice agrupado en un GUID. Esto causará un orden físico alrededor del GUID en el disco, que obviamente no tiene sentido (como ya han señalado otros)
NUNCA use un índice agrupado en un GUID? Esa es una declaración audaz. ¿Estás seguro de que no hay ejemplos de contador? – MarkPflug
Por favor nombre uno si conoce uno :-). No veo ninguna razón por la cual desees ordenar físicamente algo en torno a un GUID. – nashwan
Si el rendimiento SELECCIONAR es importante y estará SELECCIONANDO en GUID ... –
Posible duplicado de [¿Cuáles son las mejores prácticas para usar un GUID como clave principal, específicamente con respecto al rendimiento?] (http://stackoverflow.com/questions/11938044/what-are-the-best-practices-for-using-a-guid-as-a-primary-key-specifically-rega) – AHiggins
¡Haga que no se agrupe! (si debe permanecer como un GUID) – nashwan