Início / dba / Perguntas / 108952
Accepted
sharptooth
Asked: 2015-08-05 03:28:18 +0800 CST

Por que a restrição PK requer um índice separado quando eu já tenho um índice clusterizado exclusivo adequado?

  • 772

Isso faz parte da definição da tabela daqui :

CREATE TABLE [dbo].[JobItems] (
[ItemId]            UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);

CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
ON [dbo].[JobItems]([ItemId] ASC);

Este é um design herdado, então, por favor, não pergunte "por quê". De qualquer forma, quando procuro a lista de índices, vejo que há dois índices - um deles é JobItemsIndexe o outro é PK-GUID-HEREe ambos são para JobItemstabela.

Minha pergunta é...

Por que há necessidade de um índice separado para manter o PK quando eu já tenho JobItemsIndexum único e inclui a mesma coluna e, portanto, adequado para manter a restrição PK?

sql-server index

3 respostas

  1. Não precisa de um índice separado. Só é feito dessa forma porque você realmente disse que estava no script. Você poderia fazer isso com a mesma funcionalidade:

    CREATE TABLE [dbo].[JobItems] (
[ItemId]            UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [JobItemsIndex] PRIMARY KEY CLUSTERED ([ItemId] ASC)
);
    • 6
  2. Best Answer

    As outras duas respostas estão corretas porque os dois índices existem: você disse ao banco de dados para criar dois índices. Além disso, você pode agrupar sua chave primária e remover o segundo índice.

    Responder à sua pergunta sobre por que o segundo índice é "necessário" resume-se a uma limitação/requisito para bancos de dados do Sql Server Azure edition que não está presente em outras versões do Sql Server. Sql Server Enterprise/Standard/Express suporta todas as tabelas de heap. A edição SQL Server Azure não dá suporte a tabelas de heap. Meu palpite é que em algum momento eles queriam que a tabela "JobItems" fosse uma tabela heap. Quando chegou a hora de colocar o banco de dados na nuvem, eles foram forçados a ter um índice clusterizado na tabela. O desenvolvedor optou por criar um índice duplicado que é clusterizado em vez de alterar a chave primária de não clusterizada para clusterizada. Por que eles escolheram isso, talvez nunca saibamos... No entanto, esse parece ser um caminho plausível para sua situação, especialmente se essa tabela "herdada" residir fora do Azure em algum momento de sua vida.

    Também pode ser útil revisar esta pergunta e esta pergunta no StackOverflow, onde eles discutem índices clusterizados e não clusterizados na mesma coluna. A resposta mais bem avaliada na primeira pergunta afirma que pode haver um aumento de desempenho em ter os dois índices. As respostas para a segunda pergunta basicamente reiteram com mais detalhes o que outros já disseram em resposta à sua pergunta.

    • 4

  3. No seu caso particular, isso realmente não importa, pois seu índice clusterizado exclusivo e sua chave primária estão na (s) mesma (s) coluna (s), mas há duas pequenas diferenças entre os dois.

    • Uma chave primária requer que todas as colunas sejam não anuláveis.

    • Uma chave única permite valores NULL.

    • Você pode ter apenas uma chave primária.

    • Você pode ter várias chaves exclusivas.

    Qualquer um pode ser agrupado. E você pode ter apenas uma chave agrupada.

    No seu caso, no entanto, como sua chave primária e seu índice são idênticos, você pode facilmente descartar ambos e recriar sua chave primária como um índice clusterizado. Dito isto, se for uma mesa grande, não tenho certeza se me incomodaria. Eu provavelmente descartaria a chave primária (sem motivo para mantê-la) e viveria com o índice exclusivo clusterizado. Caso você esteja preocupado , isso NÃO o torna um HEAP . Você tem um índice clusterizado para não ter um heap.

    • 3

relate perguntas