Início / dba / Perguntas / 39274
Accepted
greg
Asked: 2013-04-05 08:23:36 +0800 CST

RID vs INCLUDE em um campo grande

  • 772

Eu tenho uma mesa que armazena notas 

create tblNote(  
  Id int identity(1,1),  
  ParentId  int ,   
  ParentType varchar(32),   
  NoteType varchar(32),   
  Note varchar(max),  
  CreatedBy varchar(25),   
  CreatedDate  datetime,   
  .  
  .  
  .  
  <other metadata about the note>  
)

Eu li muito recentemente sobre como o MSSS lida com índices (2005 e posteriores).

Eu tenho um índice clusterizado no ID

[Eu considerei alterar o índice clusterizado para parentId, parentType, pois é razoavelmente estreito e é estático. ]

A esmagadora porcentagem de consultas nesta tabela vai seguir as linhas de

select NOTE, createdDate, createdBy 
from tblNote 
where parentId = 12 and parentType = 'RFQ'

A pergunta que quero fazer hoje (embora qualquer feedback seja bem-vindo) é esta:

O índice NC que eu poderia adicionar é:

create index  idx_nc_note_parent(  
        parentId ,   
        parenttype  
    )  
    include (createdby, createdDate)

Isso seria útil na criação de pequenas listas de notas onde poderíamos incluir quem e quando digitar informações.

Estou hesitante em incluir um varchar(max)campo. Parece que realmente prejudicaria a quantidade do índice que seria armazenado em cache (isso é razoável ou irracional)

Supondo que eu não inclua o NOTEcampo, uma pesquisa RID será necessária para realmente buscar o conteúdo da nota, se solicitado.

Embora eu tenha lido um pouco sobre como as pesquisas de RID são caras, ainda deve ser melhor ter esse índice em vez de fazer uma varredura de tabela, CERTO?

[desculpas pelo bloco de código, adicionei os 4 espaços, mas talvez tenha feito errado? ]

sql-server

2 respostas

  1. Best Answer

    Como você disse que a maioria das consultas geralmente retornaria algumas linhas, permitir que a consulta use uma pesquisa RID (pesquisa de chave neste caso, pois a tabela possui um índice clusterizado) é perfeitamente adequado para recuperar um campo potencialmente grande. Para um sistema altamente disponível, eu não recomendaria colocar um tipo de LOB em um índice de qualquer maneira, pois isso evita reconstruções online (para versões do SQL Server anteriores a 2012). Além disso, você precisa ter muito cuidado para que o plano de consulta sempre se atenha a um plano do tipo busca e não caia em uma varredura de tabela, que pode ser muito cara. Este é um caso em que posso usar uma dica de tabela (ou um guia de plano se a consulta não puder ser modificada) mesmo que não seja absolutamente necessário.

    Outra opção é recriar o índice clusterizado na combinação de parentIde parentTypese essa combinação de valores for estática e geralmente aumentar com o tempo. Seria melhor se parentTypefosse um tipo integral, e você pode querer mudar isso de qualquer maneira para economizar espaço de armazenamento se a tabela base for, ou se tornar, grande. Considerar essa alteração também envolve observar como ela pode afetar a indexação de outras classes de consultas executadas nessa tabela.

    Se algum desses dois métodos não for rápido o suficiente para a carga de trabalho, procure implementar uma solução de cache de dados usando algo como AppFabric, que escala muito mais prontamente do que executar uma consulta SQL sempre que você precisar de dados. Isso pode ser uma grande recompensa; o custo é a complexidade adicionada.

    • 5

  2. Você pode tentar isso?

    Crie um índice em parentID e parentType para procurar IDs aplicáveis...

    Create  NonClustered Index idx_nc_note_parent On tblNote (parentID, parentType)

    Junte os IDs de volta à tabela base para extrair as informações desejadas usando o índice clusterizado...

    Select  NOTE, createdDate, createdBy
From   (Select  ID
        From    tblNote
        Where   parentID = 12
        And     parentType = 'RFQ') n
Join    tblNote tn
        On  n.ID = tn.ID
    • 1

relate perguntas