Início / dba / Perguntas / 20673
Accepted
Dai
Asked: 2012-07-11 16:37:00 +0800 CST

SQL Server 2012 - SELECT e UPDATE frequentes na coluna de bits. Índice não ajuda

  • 772

Eu tenho uma tabela SQL Server com cerca de 2 milhões de linhas, esta tabela armazena documentos textuais curtos. Aqui está o meu esquema:

CREATE TABLE Documents (
    documentId bigint IDENTITY NOT NULL,
    content nvarchar(MAX) NOT NULL,
    isIndexed bit NOT NULL
)

Eu tenho um processo indexador baseado em Lucene separado que faz isso:

SELECT TOP 1 documentId, content FROM Documents WHERE isIndexed = 0

Em seguida, ele executa a operação de indexação antes de executar isto:

UPDATE Documents SET isIndexed = 1 WHERE documentId = @documentId

Inicialmente, isso funcionou bem. Quando todos os documentos na tabela não foram indexados (ou seja, todos os isIndexedvalores eram 0), cada recuperação demorava cerca de 5 ms.

No entanto, à medida que mais e mais documentos foram indexados, o tempo de recuperação aumentou lentamente. Atualmente é cerca de 150ms - uma redução de velocidade de 30 vezes. Observo que a instrução UPDATE sempre parece ser executada em menos de 2 ms, então sei que isso não é um problema.

Desde o início, a tabela sempre teve um índice não clusterizado na coluna isIndexed, mas o plano de execução real mostra que o SQL Server usa uma varredura de índice (em vez de uma busca).

O que posso fazer para acelerar o sistema?

Estou ciente de que a coluna "isIndexed" existente é ruim por si só, mas devido ao funcionamento do indexador, ele não pode solicitar documentos diretamente pelo documentId. Por esta e outras razões, não posso aceitar respostas que não resolvam o problema imediato em questão.

sql-server performance

2 respostas

  1. Um índice na coluna de bits não ajudará em nada por causa da seletividade. Você deve considerar um índice filtrado:

    CREATE INDEX unindexed ON dbo.Documents(documentId) WHERE IsIndexed = 0;

    Você também deve incluir um ORDER BY documentIdem seu arquivo SELECT.

    Embora você deva testar isso em um ambiente de teste, porque pode ajudar, SELECTmas pode compensar isso com um arquivo UPDATE.

    • 5
  2. Best Answer

    A tabela (agora) possui os seguintes índices não agrupados:

    IX_Indexed_ASC (Non-Unique) ( IsIndexed ASC, DocumentId ASC )
IX_Indexed_DESC (Non-Unique) ( IsIndexed DESC, DocumentId ASC )
IX_IsIndexed_Filtered (Non-Unique) ( DocumentId ASC WHERE IsIndexed = 0 )
IX_DocumentId_Indexed (Unique) ( DocumentId ASC, IsIndexed ASC )

    E o índice clusterizado:

    PK_Documents ( DocumentId ASC )

    Eu mudei minha consulta para isso:

    SELECT
    TOP 1 DocumentId,
    Content,
    IsIndexed
FROM
    Documents
WHERE
    IsIndexed = 0

    para isso:

    SELECT 
    DocumentId,
    Content,
    IsIndexed

FROM
    Documents
WHERE
    DocumentId = (
        SELECT
            TOP 1 DocumentId
        FROM
            Documents
        WHERE
            IsIndexed = 0
    )

    E agora as consultas são executadas em menos de 10ms novamente. O plano de execução real informa que está executando duas operações de busca de índice em IX_Indexed_ASC e IX_DocumentId_Indexed.

    • 2

relate perguntas