Início / dba / Perguntas / 149225
Accepted
LCJ
Asked: 2016-09-10 07:23:08 +0800 CST

Índice agrupado na coluna de ordem aleatória

  • 772

Eu tenho uma tabela existente chamada “Pedidos” em nosso sistema. OrderID é a chave primária nesta tabela – é um índice clusterizado. Eu tenho uma nova tabela projetada conforme mostrado abaixo para “OrderCompanyDetails”. Tem um 1-to-1 relacionamento com a tabela Pedidos. Na nova tabela, OrderID é mantido como a chave primária agrupada.

Os dados são inseridos na nova tabela somente quando o pedido é aprovado. Portanto, o OrderID sendo inserido na nova tabela pode não estar em sequência. O OrderID 10 pode ser inserido antes do OrderID 5, dependendo de qual pedido for aprovado primeiro.

Ter o índice clusterizado em OrderID ajuda minhas consultas. Mas o índice clusterizado está em uma coluna que obtém dados em uma sequência aleatória. É um design de índice ruim? Se sim, devo adicionar uma nova coluna de identidade sem sentido com o nome OrderCompanyDetailID e torná-la um índice clusterizado?

CREATE TABLE [dbo].[Orders]
(
    [OrderID] [int] IDENTITY(1,1) NOT NULL,
    [OrderType] [char](3) NOT NULL,
    [StatusCD] [char](10) NOT NULL,
    [CreatedOnDate] [datetime] NOT NULL CONSTRAINT [DF__Orders__CreatedOn]  DEFAULT (getdate()),
    CONSTRAINT [PK_Orders] PRIMARY KEY CLUSTERED 
    (
        [OrderID] ASC
    )
)

CREATE TABLE [dbo].[OrderCompanyDetails](
    [OrderID] [int] NOT NULL,
    [POCompanyCD] [char](4) NULL,
    [VendorNo] [varchar](9) NULL,
    [CreatedOnDate] [datetime] NOT NULL CONSTRAINT [DF_OrderCompanyDetails_CreatedOn]  DEFAULT (getdate()),
    CONSTRAINT [PK_OrderCompanyDetails] PRIMARY KEY CLUSTERED 
    (
        [OrderID] ASC
    )
)

ATUALIZAR

Leia recentemente o artigo Chave de agrupamento cada vez maior – o debate sobre o índice agrupado……….novamente! . Tem um comentário nisso

Lembre-se – estreito, estático, único, sempre crescente – e geralmente uma chave substituta em vez de uma chave natural.

sql-server index

3 respostas

  1. A recomendação para índices clusterizados é que eles sejam sempre crescentes ou sempre decrescentes, mas isso não significa que devam ser. Os GUIDs não estão aumentando ou diminuindo, a menos que você esteja usando GUIDs sequenciais. A maioria das pessoas não usa GUIDs sequenciais.

    Se você está preocupado com o impacto no desempenho das divisões de página, diminua o fator de preenchimento para acomodar mais inserções antes que uma divisão de página seja necessária. Isso também é recomendado para GUIDs se o GUID for o índice clusterizado (não estou dizendo que deve ser o índice clusterizado, estou dizendo se for). Tenha cuidado com o quão baixo você o reduz, pois isso afetará o desempenho de leitura, o que provavelmente é importante para você, já que você mencionou que o índice clusterizado em OrderID ajuda suas consultas.

    • 5

  2. A resposta é Não necessariamente .

    O objetivo do índice é auxiliar na consulta da tabela após a inserção, e você diz que esse índice faz isso. O custo desta melhoria é

    1. O índice tem custos indiretos adicionais na inserção, ou seja, o novo registro deve ser classificado entre os registros existentes em termos de valores de índice agrupado.

    2. Manutenção do índice e estatísticas relacionadas para garantir que a melhoria continue após a implementação inicial. Isso pode incluir a reconstrução periódica de estatísticas e/ou índices.

    Se o custo do overhead de manutenção e/ou inserção for maior que o benefício proporcionado pelo ganho de performance em selects utilizando a tabela no contexto em que ela está operando, então o índice deve ser repensado.

    • 4
  3. Best Answer

    Obrigado pelas respostas. Decidi adicionar uma chave substituta (como coluna de identidade) em minha tabela devido aos seguintes motivos

    1. Meu cenário de uso é que a tabela tem muitas inserções.
    2. A chave substituta ajuda a manter a ordem cada vez maior do índice clusterizado.
    3. A ordem cada vez maior é importante para evitar a fragmentação e a divisão da página, conforme explicado em Chave de agrupamento cada vez maior – o debate sobre o índice agrupado……….novamente!

    Se a inserção for muito pesada (simultaneamente), ever increasing orderpode criar PAGELATCH_EXproblemas de espera. Leia esperas PAGELATCH_EX e inserções pesadas que mencionam hash partitioning with a computed columne reversão de bits

    Nota: Insert Hot Spoto problema pode aparecer se a carga de trabalho envolver muitas centenas de encadeamentos simultâneos inseridos na tabela.

    Leia também Insert Hotspotem Knee-Jerk Wait Statistics: PAGELATCH - Paul Randal , que diz o seguinte:

    Eu vi um hotspot de inserção como este surgir quando alguém tentou remover problemas de fragmentação de índice alterando uma chave de cluster GUID aleatória para uma chave de cluster de identidade int ou bigint, mas não conseguiu testar o novo esquema de tabela sob cargas de produção.

    A espera de trava pode ser analisada usando o DMV mencionado no ajuste de desempenho avançado do SQL Server - Paul Randal , que usa sys.dm_os_waiting_tasks. Consulte também o script sys.dm_os_waiting_tasks atualizado

    PAGELATCH_EX - sqlskills identifica Insert Hot Spote Page Splitcomo dois dos três motivos possíveis para PAGELATCH_EX.

    • 0

relate perguntas