Claves GUID: separar identidad pública y agrupación
Evalúe tamaño GUID, inserciones aleatorias y contención secuencial, comparando GUID público y clave interna estrecha.
Un identificador global puede ser adecuado públicamente sin ser la mejor clave agrupada. La identidad pública facilita integración y distribución; la agrupación influye en localidad, tamaño e inserciones dentro de la tabla. Son decisiones diferentes.
Medir el coste correcto
uniqueidentifier ocupa dieciséis bytes y bigint ocho. En una tabla rowstore agrupada, la clave agrupada también localiza filas desde índices no agrupados. Su anchura puede aumentar almacenamiento fuera de la tabla principal. El efecto depende de índices, compresión y estructura de filas.
NEWID distribuye inserciones por el espacio de claves. Una página llena puede necesitar trabajo adicional y divisiones. Una clave creciente puede concentrar contención en la última página. Distribuir o concentrar actividad tiene ventajas y costes; ninguna opción gana para toda carga.
El ejemplo separa una clave interna estrecha de un GUID público único. Ejecútelo en una base desechable. Es una alternativa para medir, no una instrucción universal de migración.
CREATE TABLE dbo.KeyDesignDemo
( InternalId bigint IDENTITY(1,1) NOT NULL
CONSTRAINT PK_KeyDesignDemo PRIMARY KEY CLUSTERED,
PublicId uniqueidentifier NOT NULL DEFAULT NEWID(),
CreatedAt datetime2(3) NOT NULL DEFAULT SYSUTCDATETIME(),
Payload nvarchar(200) NOT NULL,
CONSTRAINT UQ_KeyDesignDemo_PublicId UNIQUE NONCLUSTERED(PublicId)
);
INSERT dbo.KeyDesignDemo(Payload) VALUES(N'example');
SELECT InternalId,PublicId FROM dbo.KeyDesignDemo;
Buscar PublicId utiliza su índice único y puede requerir otra búsqueda para Payload. Si solo necesita InternalId, ese acceso adicional puede evitarse. Incluya columnas únicamente cuando su beneficio compense espacio y mantenimiento.
Límites de la secuencialidad
NEWSEQUENTIALID reduce inserciones aleatorias cuando funciona como default de uniqueidentifier. No reemplaza NEWID en cualquier expresión. Su orden después de reinicios o cambios de equipo no representa un reloj de negocio. Tampoco convierta el identificador en secreto de autorización.
Ser secuencial no reduce dieciséis bytes. Puede desplazar presión hacia una zona caliente de inserción. Distinga esperas de latches, bloqueos transaccionales y almacenamiento. Una corrección de fragmentación no necesariamente resuelve contención en la última página.
Fill factor reserva espacio durante construcción, sin mantenerlo libre permanentemente. Reducirlo puede disminuir algunas divisiones y aumentar páginas y lecturas. Elija según crecimiento medido, no una regla para todos los índices.
Comparar toda la aplicación
Mida inserciones concurrentes, búsquedas públicas, joins internos e informes de rango. Compare tamaño total, generación de log, actividad de páginas, rendimiento y latencia extrema. Acelerar inserciones empeorando búsquedas habituales no garantiza mejora global.
Cambiar una clave agrupada existente es una migración estructural. Revise claves externas, índices dependientes, replicación y supuestos de aplicación. Añadir InternalId no redirige relaciones GUID existentes. Decida expresamente qué hijos conservan GUID y cuáles cambian a clave interna.
Para escritores distribuidos, defina generación y combinación de identificadores. Una identity local no es globalmente única. Mantener una identidad externa puede preservar integración mientras la clave interna permanece local.
Pruebe failover, cargas masivas, eliminaciones seguidas de inserciones y datos mayores que el buffer pool. Los permisos siguen siendo obligatorios aunque los identificadores resulten difíciles de adivinar. Mida además el mantenimiento del índice adicional en el diseño separado. Incluya el coste de los joins de las tablas hijas, porque puede dominar el ahorro observado en la tabla principal. El resultado debe ser una decisión basada en carga, no una regla absoluta sobre GUID.
Referencias técnicas: Microsoft Learn: Index design · Microsoft Learn: NEWSEQUENTIALID.