Início / dba / Perguntas / 331535
Accepted
Naveed Ahmed
Asked: 2023-09-25 05:37:35 +0800 CST

Melhor abordagem para chave primária CLUSTERED vs NONCLUSTERED

  • 772

Suponha que eu tenha uma tabela com as colunas abaixo:

Id int identidade, UserId

Qual seria a melhor abordagem:

Making Id PRIMARY KEY CLUSTERED
Creating NONCLUSTERED Index on UserId

OU

Making Id PRIMARY KEY CLUSTERED
Creating NONCLUSTERED Index on UserId, Id

OU

Making Id PRIMARY KEY NONCLUSTERED
Creating CLUSTERED Index on UserId

OU

Making Id PRIMARY KEY NONCLUSTERED
Creating CLUSTERED Index on UserId, Id

OU

Just making a composite CLUSTERED PRIMARY KEY including both columns Id, UserId

Atualizar

Atualizar/excluir é baseado em UserId e Id, enquanto as recuperações são baseadas em UserId.

Eu leio principalmente a tabela por ID do usuário. Como um usuário pode ter vários registros nesta tabela e para modificar um registro específico de um usuário, por exemplo, para operações de atualização/exclusão, eu precisaria de id e userid para identificar exclusivamente o registro.

sql-server

2 respostas

  1. Best Answer
    • a opção 1 é a opção padrão, quero dizer, eu recomendaria fazer isso sem saber de nada
    • a opção 2 é igual à opção 1 - mesma utilização de espaço, mesmo plano
    • a opção 3 é boa se você PRECISA ter o id como chave primária, mas principalmente ler a tabela pelo ID do usuário
    • a opção 4 tem as mesmas desvantagens da opção 3, mas é mais cara para outros índices não clusterizados. A única coisa boa sobre isso - ele não terá um complemento de 4 bytes para 'torná-lo único'.
    • a opção 5 é boa se você puder alterar a definição da chave primária e
      a referência à sua tabela for adequada para ter uma chave composta (userid, id). Certifique-se de que o pedido seja (userid, id) e não (id, userid)

    Na opção 5 - se houver uma tabela filha ela deverá referenciar não apenas por id, mas por userid e id

    alter table child_table add constraint fk foreign key (user_id, parent_id) references mytable

    Atualização Com base na resposta acima do comentário de SergeyA e Dan Guzman. Parece que a opção 5, ou seja, chave composta (userid, id) é a melhor opção. Porque provavelmente otimizará a recuperação de linhas por UserID e também atualizará/excluirá operações quando ambas as colunas forem especificadas.

    Obrigado a todos por sua ajuda.

    • 1

  2. Tornando o Id PRIMARY KEY CLUSTERED e criando o índice NONCLUSTERED no UserId:

    • Melhor opção se você consultar com base no ID do usuário.

    Tornando o Id PRIMARY KEY CLUSTERED e criando o índice NONCLUSTERED no UserId, Id:

    • Útil apenas quando as consultas envolvem UserId e Id.

    Tornando o Id PRIMARY KEY NONCLUSTERED e criando o índice CLUSTERED no UserId:

    • Melhor opção se você filtrar usando o ID do usuário

    Tornando Id PRIMARY KEY NONCLUSTERED e criando índice CLUSTERED em UserId, Id:

    • Será adequado ao consultar o ID do usuário e o ID, no entanto, tenha cuidado ao inserir/atualizar, pois o desempenho será afetado devido ao índice clusterizado.

    Fazendo uma CLUSTERED PRIMARY KEY composta incluindo Id de ambas as colunas, UserId:

    • Se você estiver usando junções em ambas as colunas, esta etapa será útil.
    • -1

relate perguntas