Pergunta de duas partes aqui.
Temos uma tabela grande (entre 1-2 milhões de linhas) com operações DML muito frequentes nela. Durante os períodos de baixo volume, temos um trabalho de agente para remover as linhas mais antigas para manter o tamanho das tabelas sob controle. ele usa o CTE abaixo, que está causando muito bloqueio quando roda:
;with agent_cte (queue_id) as
(
select top (3000) queue_id
from Table_A with (updlock, readpast)
where state in ('success','error','reject','failed','deleted')
and modify_timestamp <= DATEADD(dd,- 5,getdate())
order by modify_timestamp asc
)
delete from agent_cte
;
Eu reescrevi isso para usar uma tabela temporária para acelerar a consulta e reduzir o bloqueio, mas estou encontrando uma grande diferença de desempenho entre usar IN
e EXISTS
determinar quais linhas excluir.
IN
versão:
-- Create temp Table
create table #Table_AToDelete
(Queue_id uniqueidentifier,
PRIMARY KEY(Queue_id)
);
-- grab top 3k queue_id's older than 5 days, insert into temp table
Insert into #Table_AToDelete
select top (3000) queue_id
from Table_A with (nolock)
where state in ('success','error','reject','failed','deleted')
and modify_timestamp <= DATEADD(dd,- 5,getdate())
-- delete the rows from table_A based on rows in temp table
delete
from Table_A
where queue_id in (select queue_id from #Table_AToDelete)
Esta versão é executada em 40 a 50 segundos, no entanto, quando substituo a última linha da instrução delete pela seguinte:
where exists(select queue_id from #Table_AToDelete)
Ainda está funcionando depois de 2 minutos, então cancelei.
Então, as perguntas:
- Já vi tabelas temporárias usadas para ajudar no bloqueio e no desempenho antes, mas não entendo completamente POR QUE isso funcionaria melhor do que usar um CTE? Nós temos um índice em
Queue_id
. - Por que há uma grande diferença de desempenho entre
IN
eEXISTS
na exclusão?
Algum feedback sobre como ajustar isso para ter um desempenho melhor ou reduzir ainda mais o bloqueio?
Mais algumas notas:
- Tanto o CTE quanto a tabela temporária estão disponíveis usando colar o plano (links acima).
- Existem FKs para duas outras tabelas com atualização e exclusão em cascata, e o plano CTE gasta mais tempo na exclusão, enquanto a versão da tabela temporária gasta mais tempo na tabela principal.
- De um modo geral, há benefícios de desempenho ao usar uma tabela temporária como esta em comparação com uma CTE?
- Não tenho permissão para postar esquemas de tabelas, então peço desculpas se os planos não forem informações suficientes.
Também vou testar usando uma visão como neste artigo .
esquisito
O problema de desempenho em ambas as consultas não tem nada a ver com CTE vs. tabela temporária. Vejo que há uma diferença de tempo, mas me ouça um pouco.
apenas apague
Na exclusão direta, você gasta mais tempo excluindo tabelas, não selecionando-as.
As esperas nesta consulta estão todas relacionadas à leitura e gravação no disco:
#mesa temporária
O plano de consulta para a exclusão da tabela #temp mostra o maior tempo gasto nos mesmos dois locais (apenas mais tempo):
As esperas para esta consulta têm os mesmos gargalos de antes, apenas mais deles:
diferenças
Dadas as dificuldades de hardware que ambas as consultas enfrentam, eu meio que esperaria que as diferenças de tempo não fossem repetíveis ou confiáveis, mas mais uma questão de acaso.
Como elas são repetíveis, você deve ter o cuidado de aplicar as mesmas dicas a ambas as consultas. Sua primeira consulta foi
(updlock, readpast)
especificada. Ignorar bloqueios de linha por meio dareadpast
dica pode ser o motivo da diferença pronunciada aqui.Dos documentos :
Como essa dica de bloqueio não faz muito sentido aqui, tente usar uma dica
paglock
outablock
com sua consulta para ignorar o bloqueio em nível de linha.Observe as estatísticas de espera novamente:
Na consulta mais lenta, a contagem de espera é aproximadamente 2x da consulta mais rápida.
Independentemente disso, o hardware em que você está é incompatível com uma carga de trabalho de banco de dados de produção.
Supondo que na tabela real exista também uma coluna chamada queue_id.