Como otimizar a declaração de junção do servidor SQL em execução com milhões de registos

Eu uso o servidor SQL 2014 e preciso atualizar uma nova coluna de tipo de datetime adicionado em uma tabela. Existem duas tabelas relacionadas (ambas têm > 30 milhões de registros):

TableA:

CategoryID, itemID, dataCreated, deleted, some other string properties. 

Esta tabela contém múltiplos registos para cada item com diferentes datecreated.

TableB:

CategoryID, itemID, LatestUpdatedDate (This is the new added column)

ambos categoryID e itemID fazem parte de um índice nesta tabela.

para actualizar o tableB LatestUpdatedDate da tabela A em matched CategoryID e ItemID, usei a seguinte junção declaração:

merge [dbo].[TableB] with(HOLDLOCK) as t
using 
(
    select CategoryID,itemID, max(DateCreated) as LatestUpdatedDate 
    from dbo.TableA 
    where TableA.Deleted = 0
    group by CategoryID,itemID
) as s on t.CategoryID = s.CategoryID and t.itemID = s.itemID

when matched then
    update
    set t.LatestUpdatedDate = s.LatestUpdatedDate

when not matched then
    insert (CategoryID, itemID, LatestUpdatedDate)
    values (s.CategoryID, s.itemID)
Dado o facto de milhões de discos em ambas as tabelas, Como posso optimizar este guião? Ou há outra maneira de atualizar a tabela com melhor desempenho?

Nota: Este é um script único e o DB está em directo, haveria um trigger adicionado ao tableA contra o insert para actualizar a data no tableB no futuro.

Author: marc_s, 2017-02-13

1 answers

De acordo com a optimização do desempenho da demonstração da junção , O melhor que pode fazer é:

  • crie um índice nas colunas de junção na tabela de origem que seja único e cobrindo.
  • crie um índice único agrupado nas colunas de junção na tabela de destino.

Você pode obter uma melhoria de desempenho durante {[[0]} criando um índice em TableA em (Deleted, CategoryID, itemID) INCLUDE(DateCreated). No entanto, como esta é uma operação pontual, os recursos (tempo, CPU, espaço) necessários para criar este índice provavelmente não irá compensar os ganhos de desempenho vis-a-vis executando a consulta como está e confiando no seu índice existente.

 2
Author: Serge, 2017-02-13 02:52:47