Los GUID son problemáticos como claves agrupadas debido a la alta aleatoriedad. Paul Randal abordó este problema en la última columna de preguntas y respuestas de Technet Magazine:Me gustaría usar un GUID como clave de índice agrupado, pero los demás argumentan que puede generar problemas de rendimiento con los índices. ¿Es esto cierto y, de ser así, puede explicar por qué?
Ahora tenga en cuenta que la discusión es específicamente sobre agrupado índices Dice que quiere usar la columna como 'ID', eso no está claro si se refiere a ella como clave agrupada o solo como clave principal. Por lo general, los dos se superponen, por lo que supondré que desea usarlo como índice agrupado. Las razones por las que es una mala elección se explican en el enlace al artículo que mencioné anteriormente.
Para los í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. Nuevamente, la aleatoriedad de los GUID introduce divisiones de página y fragmentación, ya sea solo en el nivel de índice no agrupado (un problema mucho menor).
Hay muchas leyendas urbanas que rodean el uso de GUID que los condenan en función de su tamaño (16 bytes) en comparación con un int (4 bytes) y prometen una pérdida de rendimiento horrible si se usan. Esto es un poco exagerado. Una clave de tamaño 16 puede seguir siendo una clave muy eficaz, en un modelo de datos diseñado correctamente. Si bien es cierto que ser 4 veces más grande que un int da como resultado más páginas sin hojas de menor densidad en los índices, esto no es una preocupación real para la gran mayoría de las tablas. La estructura del árbol b es un árbol naturalmente bien equilibrado y la profundidad del recorrido del árbol rara vez es un problema, por lo que buscar un valor basado en la clave GUID en lugar de una clave INT tiene un rendimiento similar. Un recorrido de página de hoja (es decir, un escaneo de tabla) no mira las páginas que no son de hoja, y el impacto del tamaño de GUID en el tamaño de página suele ser bastante pequeño, ya que el registro en sí es significativamente más grande que los 12 bytes adicionales introducidos. por el GUID. Así que tomaría el consejo de oír decir basado en 'son 16 bytes frente a 4' con un grano de sal bastante grande. Analice caso por caso y decida si el tamaño del impacto hace una diferencia real:¿cuántos otros columnas están en la tabla (es decir, cuánto impacto tiene el tamaño de GUID en las páginas hoja) y cuántas referencias lo están usando (es decir, cuántas otras las tablas aumentarán debido al hecho de que necesitan almacenar una clave externa más grande).
Menciono todos estos detalles en una especie de defensa improvisada de los GUID porque últimamente han recibido mucha mala prensa y parte no se la merecen. Tienen sus méritos y son indispensables en cualquier sistema distribuido (en el momento en que se habla de movimiento de datos, ya sea a través de un marco de replicación o sincronización o lo que sea). He visto malas decisiones basadas en la mala reputación de GUID cuando se evitaron sin la debida consideración. Pero es cierto, si tiene que usar un GUID como clave agrupada, asegúrese de solucionar el problema de la aleatoriedad:use GUID secuenciales cuando sea posible.
Y finalmente, para responder a su pregunta:si no tiene un específico razón para usar GUID, use INT.
