A busca de índice NONCLUSTERED no mslid é lenta

Eu estaria interessado no número de linhas totais que você tem em sua Parts.ManufacturingDatatabela e qual é o tempo de execução total atualmente para sua consulta. O número de linhas que o plano de execução diz que está retornando (aproximadamente 32 milhões) realmente faz sentido para sua consulta?

Talvez você descubra que um índice filtrado economiza um pouco de tempo, pois pré-materializa apenas os dados que você deseja. Que tal um índice com essa definição, faz alguma diferença?

CREATE NONCLUSTERED INDEX IX_ManufacfuringData_MSLID_Filtered ON Parts.ManufacturingData (MSLID) WHERE MSLID IS NOT NULL;

Observe que você não precisa fazer nada diferente em sua consulta para usar o índice filtrado acima depois de criado. Mas você deve verificar o plano de execução para garantir que o otimizador escolheu esse novo índice em relação a quaisquer outros índices em sua tabela quando a consulta for executada.

Se isso não fizer diferença, a outra coisa que você pode tentar é adicionar a FORCESCANdica à sua consulta assim:

select  partid,mslid 
into ExtractReports.dbo.manufactureparts
from parts.manufacturingdata m with(nolock, FORCESCAN)
where mslid is  not null

Isso diria ao otimizador para usar uma operação de varredura em vez de buscar seus dados. Isso geralmente teria melhor desempenho se aproximadamente a maioria dos seus dados na tabela atendesse aos critérios de sua WHEREcláusula. Ou seja, geralmente é mais rápido varrer toda a tabela nesse ponto e filtrar as linhas indesejadas, do que procurar em tantas linhas. Mas é difícil dizer se isso ajudará suas circunstâncias sem conhecer seus dados ou testá-los.

Observe que as dicas de consulta devem ser usadas com cautela e somente em circunstâncias em que métodos alternativos de otimização não são possíveis. Algumas dicas de consulta limitam o número de planos de execução disponíveis que o otimizador pode escolher e, portanto, podem resultar em um erro quando determinadas consultas que usam essas dicas tentam ser executadas.

Nesse caso, acho que usar a FORCESCANdica provavelmente está ok, pois sua consulta é simples e não acredito que ela limite o número de planos de consulta tanto quanto outras dicas.

Talvez você possa tentar com um índice columnstore não clusterizado nos mesmos campos. Isso pode levar a um modo de lote e compactação para que você possa poupar algo na leitura.

documento da microsoft

exemplo:

CREATE NONCLUSTERED COLUMNSTORE INDEX 
[NCCIX_Parts_ManufacturingData_MSLID] ON [Parts].[ManufacturingData]
 (
     [MSLID] ASC
 )
GO

Sua busca de índice está retornando 32 milhões de linhas. Você tem um bom plano, isso é apenas um monte de dados para ler.

Você pode considerar criar explicitamente a tabela de destino antes de tentar inseri-la.

Além de outras respostas certas, você também pode tentar um método alternativo para melhorar o desempenho, que pode ser criar uma exibição indexada como abaixo:

CREATE VIEW parts.manufacturingdata_Indexed
WITH SCHEMABINDING AS
select partid,mslid from parts.manufacturingdata m with(nolock)
where mslid is  not null

Depois de criar a visualização acima, crie o índice conforme abaixo:

CREATE UNIQUE CLUSTERED INDEX IX_manufacturingdata
    ON parts.manufacturingdata_Indexed
     (partid,mslid);

Após a criação da visualização e do índice acima, você pode reescrever sua consulta como:

insert into ExtractReports.dbo.manufactureparts
(select * from parts.manufacturingdata_Indexed)

Estou alterando a consulta para insert intoem vez de select * intoreutilização de código. No caso de select into, você sempre precisa descartar a tabela subjacente.

Por favor, deixe-nos saber se isso ajuda.