GUID son problemáticos como teclas agrupadas a causa de la alta aleatoriedad.Este tema fue abordado por Paul Randal en el último TechNet Magazine Q & Una columna: I'd like to use a GUID as the clustered index key, but the others are arguing that it can lead to performance issues with indexes. Is this true and, if so, can you explain why?
Ahora tener en cuenta que la discusión es específicamente sobre agrupados índices. Usted dice que quiere usar la columna como 'ID', no está claro si la quiere decir como clave agrupada o solo como clave principal. Por lo general, los dos se superponen, así que supongo que desea usarlo como índice agrupado. Las razones por las cuales esa es una mala elección se explican en el enlace al artículo que mencioné anteriormente.
Para índices no agrupados Los GUID todavía tienen algunos problemas, pero no tan grandes como cuando son la clave agrupada más a la izquierda de la tabla. De nuevo, la aleatoriedad de los GUID introduce divisiones de páginas y fragmentación, ya sea en el nivel de índice no agrupado (un problema mucho más pequeño).
Hay muchas leyendas urbanas que rodean el uso de GUID que las condenan en función de su tamaño (16 bytes) en comparación con un int (4 bytes) y prometen una fatalidad de rendimiento horrible si se usan. Esto es ligeramente exagerado. Una clave de tamaño 16 puede ser una clave muy relevante aún, en un modelo de datos diseñado correctamente. Si bien es cierto que ser 4 veces más grande que un int resulta en más páginas no hojas de menor densidad en índices, esto no es una preocupación real para la gran mayoría de las tablas. La estructura b-tree es un árbol naturalmente equilibrado y la profundidad del recorrido del árbol es rara vez un problema, por lo que buscar un valor basado en la clave GUID en comparación con una clave INT es similar en rendimiento. Un recorrido de hoja de página (es decir, un escaneo de tabla) no mira las páginas que no son hojas, y el impacto del tamaño de GUID en el tamaño de página suele ser bastante pequeño, ya que el registro es significativamente mayor que los 12 bytes adicionales introducidos por el GUID. Así que tomaría el consejo de escuchar y decir basado en "16 bytes vs. 4" con un grano de sal bastante grande. Analice caso por caso y decida si el impacto del tamaño hace una diferencia real: cuántas columnas otras están en la tabla (es decir, cuánto impacto tiene el tamaño GUID en las páginas hoja) y cuántas referencias la están usando (es decir, cuántas otras tablas aumentarán debido al hecho de que necesitan almacenar una clave externa más grande).
Estoy llamando a todos estos detalles en una especie de defensa improvisada de GUID porque últimamente han recibido mucha mala prensa y algunos no se merecen. Tienen sus ventajas y son indispensables en cualquier sistema distribuido (en el momento en que se habla de movimiento de datos, ya sea a través de la replicación o el marco de sincronización o lo que sea). He visto malas decisiones basadas en la mala reputación del GUID cuando fueron rechazadas sin la consideración adecuada. Pero es cierto, si tiene que usar un GUID como clave agrupada, asegúrese de abordar el problema de la aleatoriedad: use las guías secuenciales cuando sea posible.
Y, por último, para responder a su pregunta: si usted no tiene una razón específicautilizar GUID, utilice intercepciones.
Si el rendimiento de int frente a GUID es una importante fuente de preocupación para su cuello de botella de datos, considérese ** muy ** afortunado. La mayoría de las otras aplicaciones se topan con otros problemas más urgentes antes de que esto se convierta en un factor. –
Además, los GUID pueden ser útiles al hacer declaraciones Insert, ya que puede crear su GUID en C# per se, luego simplemente haga la inserción y no tenga que esperar a que la base de datos le devuelva el nuevo identificador. –
@Joe Chung No hay ningún problema de rendimiento en este momento, porque la base de datos todavía se está diseñando. – mkchandler