Chaves GUID: separar identidade pública e clustering

Um identificador global pode ser adequado publicamente sem ser a melhor chave clusterizada. Identidade pública facilita integração e distribuição; clustering influencia localidade, tamanho e inserções dentro da tabela. São decisões distintas.

Medir o custo certo

uniqueidentifier ocupa dezesseis bytes e bigint oito. Em uma tabela rowstore clusterizada, a chave clusterizada também localiza linhas pelos índices não clusterizados. Sua largura pode aumentar armazenamento além da tabela principal. O efeito depende de índices, compressão e formato das linhas.

NEWID espalha inserções pelo espaço de chaves. Uma página cheia pode exigir trabalho extra e divisões. Uma chave crescente pode concentrar contenção na última página. Distribuir ou concentrar atividade tem consequências; nenhuma alternativa vence em qualquer carga.

O exemplo separa uma chave interna estreita de um GUID público único. Execute em banco descartável. É uma opção para medir, não uma ordem universal de migração.

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 usa seu índice único e pode exigir outro lookup para Payload. Se apenas InternalId for necessário, esse acesso adicional pode ser evitado. Inclua colunas somente quando o benefício compensar espaço e manutenção.

Limites da sequência

NEWSEQUENTIALID reduz inserções aleatórias quando usado como default de uniqueidentifier. Não substitui NEWID em qualquer expressão. Sua ordem após reinício ou mudança de máquina não representa um relógio de negócio. Também não transforme o identificador em segredo de autorização.

Ser sequencial não reduz os dezesseis bytes. Pode deslocar pressão para uma área quente de inserção. Diferencie esperas de latch, bloqueios transacionais e armazenamento. Corrigir fragmentação não necessariamente resolve contenção na última página.

Fill factor reserva espaço na construção, sem mantê-lo livre para sempre. Reduzi-lo pode diminuir algumas divisões e aumentar páginas e leituras. Escolha segundo crescimento medido, não uma política uniforme para todo índice.

Comparar a aplicação inteira

Meça inserções concorrentes, buscas públicas, joins internos e relatórios por faixa. Compare tamanho total, geração de log, atividade de páginas, throughput e latência extrema. Acelerar inserts piorando consultas frequentes não garante melhora global.

Alterar uma chave clusterizada existente é uma migração estrutural. Revise chaves estrangeiras, índices dependentes, replicação e pressupostos do aplicativo. Adicionar InternalId não redireciona relações GUID existentes. Decida explicitamente quais filhos mantêm GUID e quais mudam para chave interna.

Para escritores distribuídos, defina geração e combinação dos identificadores. Uma identity local não é globalmente única. Preservar identificação externa pode manter a integração enquanto a chave interna permanece local.

Teste failover, cargas em massa, exclusões seguidas de inserções e dados maiores que o buffer pool. Permissões continuam obrigatórias mesmo quando identificadores são difíceis de adivinhar. Meça também manutenção do índice adicional no desenho separado. Inclua o custo dos joins nas tabelas filhas, pois ele pode superar a economia observada na tabela principal. Compare os mesmos volumes e padrões de leitura em todas as alternativas. A conclusão deve vir da carga real, não de uma regra absoluta sobre GUID.

Referências técnicas: Microsoft Learn: Index design · Microsoft Learn: NEWSEQUENTIALID.