¿Cuáles son las mejores prácticas para usar un GUID como clave principal, específicamente con respecto al rendimiento?

Tengo una aplicación que usa GUID como clave principal en casi todas las tablas y he leído que hay problemas de rendimiento al usar GUID como clave primaria. Honestamente, no he visto ningún problema, pero estoy a punto de comenzar una nueva aplicación y todavía quiero usar los GUID como las Claves primarias, pero estaba pensando en usar una Clave primaria compuesta (El GUID y quizás otro campo .)

Estoy usando un GUID porque son agradables y fáciles de administrar cuando tienes diferentes entornos como bases de datos de "producción", "prueba" y "dev", y también para la migración de datos entre bases de datos.

Usaré Entity Framework 4.3 y quiero asignar el Guid en el código de la aplicación, antes de insertarlo en la base de datos. (es decir, no quiero dejar que SQL genere el Guid).

¿Cuál es la mejor práctica para crear Claves primarias basadas en GUID, para evitar los supuestos golpes de rendimiento asociados con este enfoque?

Los GUID pueden parecer una opción natural para su clave principal, y si realmente debe hacerlo, probablemente podría argumentar que la usará para la CLAVE PRIMARIA de la tabla. Lo que recomiendo encarecidamente que no haga es usar la columna GUID como clave de agrupación , que SQL Server hace de manera predeterminada, a menos que se lo indique específicamente.

Realmente necesitas mantener dos problemas separados:

1. la clave primaria es una construcción lógica, una de las claves candidatas que identifica de manera única y confiable cada fila de su tabla. Esto puede ser cualquier cosa, realmente, un INT, un GUID, una cadena, elija lo que tenga más sentido para su escenario.

2. la clave de agrupamiento (la columna o columnas que definen el "índice agrupado" en la tabla) - esto es algo relacionado con el almacenamiento físico , y aquí, un tipo de datos pequeño, estable y en constante aumento es su mejor elección, INTo BIGINTcomo su Opción por defecto.

Por defecto, la clave principal en una tabla de SQL Server también se usa como clave de agrupación, ¡pero eso no tiene por qué ser así! Personalmente, he visto ganancias masivas de rendimiento al dividir la Clave primaria / agrupada basada en GUID anterior en dos claves separadas: la clave primaria (lógica) en el GUID y la clave de agrupamiento (orden) en una INT IDENTITY(1,1)columna separada .

Como Kimberly Tripp , la reina de la indexación, y otros han declarado muchas veces, GUIDya que la clave de agrupamiento no es óptima, ya que debido a su aleatoriedad, conducirá a una fragmentación masiva de páginas e índices y a un mal rendimiento en general.

Sí, lo sé, hay newsequentialid()en SQL Server 2005 y versiones posteriores, pero incluso eso no es secuencial y completamente secuencial y, por lo tanto, también sufre los mismos problemas que el GUID, solo que un poco menos prominente.

Luego, hay otro problema a considerar: la clave de agrupación en una tabla se agregará a todas y cada una de las entradas de todos y cada uno de los índices no agrupados en su tabla, por lo que realmente desea asegurarse de que sea lo más pequeña posible. Por lo general, una INTcon más de 2 mil millones de filas debería ser suficiente para la gran mayoría de las tablas, y en comparación con una GUIDclave de agrupación, puede ahorrarse cientos de megabytes de almacenamiento en el disco y en la memoria del servidor.

Cálculo rápido: usando INTvs. GUIDcomo clave principal y de agrupamiento:

• Tabla base con 1'000'000 filas (3.8 MB vs. 15.26 MB)
• 6 índices no agrupados (22.89 MB frente a 91.55 MB)

TOTAL: 25 MB frente a 106 MB , ¡y eso es solo en una sola mesa!

Algo más para pensar: cosas excelentes de Kimberly Tripp: léelo, léelo de nuevo, ¡digerirlo! Es el evangelio de indexación de SQL Server, de verdad.

• GUID como PRIMARY KEY y / o clustered key
• El debate sobre el índice agrupado continúa
• Clave de agrupamiento cada vez mayor: ¡el debate del índice agrupado .......... nuevamente!
• El espacio en disco es barato, ¡ese no es el punto!

PD: por supuesto, si se trata de unos pocos cientos o miles de filas, la mayoría de estos argumentos realmente no tendrán un gran impacto en usted. Sin embargo: si entras en las decenas o cientos de miles de filas, o comienzas a contar en millones, entonces esos puntos se vuelven cruciales y muy importantes de entender.

Actualización: si desea tener su PKGUIDcolumna como su clave principal (pero no su clave de agrupación) y otra columna MYINT( INT IDENTITY) como su clave de agrupación, use esto:

CREATE TABLE dbo.MyTable
(PKGUID UNIQUEIDENTIFIER NOT NULL,
 MyINT INT IDENTITY(1,1) NOT NULL,
 .... add more columns as needed ...... )

ALTER TABLE dbo.MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY NONCLUSTERED (PKGUID)

CREATE UNIQUE CLUSTERED INDEX CIX_MyTable ON dbo.MyTable(MyINT)

Básicamente: solo tiene que decir explícitamente la PRIMARY KEYrestricción que es NONCLUSTERED(de lo contrario, se crea como su índice agrupado, de forma predeterminada), y luego crea un segundo índice que se define comoCLUSTERED

Esto funcionará, y es una opción válida si tiene un sistema existente que necesita ser "rediseñado" para su rendimiento. Para un nuevo sistema, si comienzas desde cero y no estás en un escenario de replicación, siempre elegiría ID INT IDENTITY(1,1)como mi clave principal agrupada, ¡mucho más eficiente que cualquier otra cosa!

He estado usando GUID como PK desde 2005. En este mundo de bases de datos distribuidas, es absolutamente la mejor manera de combinar datos distribuidos. Puede disparar y olvidar tablas de fusión sin la preocupación de que las entradas coincidan en tablas unidas. Las combinaciones de GUID se pueden copiar sin ninguna preocupación.

Esta es mi configuración para usar GUID:

1. PK = GUID. Los GUID se indexan de forma similar a las cadenas, por lo que las tablas de filas altas (más de 50 millones de registros) pueden necesitar particiones de tabla u otras técnicas de rendimiento. SQL Server se está volviendo extremadamente eficiente, por lo que los problemas de rendimiento son cada vez menos aplicables.

2. PK Guid es un índice NO agrupado. Nunca agrupe el índice de un GUID a menos que sea NewSequentialID. Pero incluso entonces, un reinicio del servidor provocará interrupciones importantes en el pedido.

3. Agregue ClusterID Int a cada tabla. Este es su índice agrupado ... que ordena su mesa.

4. Unirme a ClusterIDs (int) es más eficiente, pero trabajo con 20-30 millones de tablas de registros, por lo que unirme a GUIDs no afecta visiblemente el rendimiento. Si desea un rendimiento máximo, use el concepto ClusterID como clave principal y únase a ClusterID.

Aquí está mi tabla de correo electrónico ...

CREATE TABLE [Core].[Email] (
    [EmailID]      UNIQUEIDENTIFIER CONSTRAINT [DF_Email_EmailID] DEFAULT (newsequentialid()) NOT NULL,        
    [EmailAddress] NVARCHAR (50)    CONSTRAINT [DF_Email_EmailAddress] DEFAULT ('') NOT NULL,        
    [CreatedDate]  DATETIME         CONSTRAINT [DF_Email_CreatedDate] DEFAULT (getutcdate()) NOT NULL,      
    [ClusterID] INT NOT NULL IDENTITY,
    CONSTRAINT [PK_Email] PRIMARY KEY NonCLUSTERED ([EmailID] ASC)
);
GO

CREATE UNIQUE CLUSTERED INDEX [IX_Email_ClusterID] ON [Core].[Email] ([ClusterID])
GO

CREATE UNIQUE NONCLUSTERED INDEX [IX_Email_EmailAddress] ON [Core].[Email] ([EmailAddress] Asc)

Actualmente estoy desarrollando una aplicación web con EF Core y aquí está el patrón que uso:

Todas mis clases (tablas) y un int PK y FK. Tengo una columna adicional con el tipo Guid (generado por el constructor de c #) con un índice no agrupado.

Todas las uniones de la tabla dentro de EF se administran a través de las teclas int, mientras que todo el acceso desde el exterior (controladores) se realiza con las Guías.

Esta solución permite no mostrar las claves int en las URL pero mantiene el modelo ordenado y rápido.

Si usa GUID como clave principal y crea un índice agrupado, le sugiero que use el valor predeterminado NEWSEQUENTIALID ()

Este enlace lo dice mejor de lo que podría y me ayudó en la toma de decisiones. Por lo general, opto por un int como clave principal, a menos que tenga una necesidad específica de no hacerlo y también dejo que el servidor SQL genere / mantenga automáticamente este campo a menos que tenga alguna razón específica para no hacerlo. En realidad, las preocupaciones de rendimiento deben determinarse en función de su aplicación específica. Aquí hay muchos factores en juego, que incluyen, entre otros, el tamaño de base de datos esperado, la indexación adecuada, la consulta eficiente y más. Aunque las personas pueden estar en desacuerdo, creo que en muchos escenarios no notará una diferencia con ninguna de las opciones y debe elegir qué es más apropiado para su aplicación y qué le permite desarrollarse más fácil, más rápido y de manera más efectiva (si nunca completa la aplicación) ¿Qué diferencia hace el resto :).

https://web.archive.org/web/20120812080710/http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

PD: No estoy seguro de por qué usarías un PK compuesto o qué beneficio crees que te daría.

La mayoría de las veces no debe usarse como la clave principal para una tabla porque realmente afecta el rendimiento de la base de datos. enlaces útiles sobre el impacto de GUID en el rendimiento y como clave principal.

1. https://www.sqlskills.com/blogs/kimberly/disk-space-is-cheap/
2. https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/

Tener identificaciones secuenciales hace que MUCHO sea más fácil para un pirata informático o minero de datos comprometer su sitio y sus datos. Tenga eso en cuenta al elegir un PK para un sitio web.