Eu tenho duas tabelas tb1 e tb2, tb1 não possui nenhum índice nela. Preenchi tb1 com 1.000.000 linhas e tb2 tem 500 linhas e com um índice clusterizado na coluna ID.
Para entender a junção de loop aninhado, usei a consulta abaixo:
SELECT *
FROM tb1
INNER JOIN tb2 ON tb1.id=tb2.id
OPTION(loop join);
Eu tenho abaixo do plano de execução para isso:
O Tb1 que não possui índice é digitalizado e o custo é de 2%, enquanto o índice está sendo usado no tb2 e o custo é de 98%.
Minha pergunta é:
- Como entender o custo estimado do operador mostrado para o recorte acima (138.236)
- Do recorte acima da varredura da tabela (cujo custo é de 2%), o número de execuções é 24, isso significa que o sql lê linhas em lotes armazenados na memória e, para cada linha, faz uma operação de busca de tbl2?
Alguém pode me explicar o plano de execução e também quaisquer ponteiros para saber mais sobre varredura de força, índice de força quando pressionei F4 depois de clicar em um operador.
A tabela heap é totalmente verificada apenas uma vez, mas a busca de índice é executada 1.000.000 vezes. O otimizador estima que um milhão de buscas neste caso representará 98,4% do custo total de execução da consulta, enquanto uma única varredura paralela da tabela heap representará 0,9% do custo.
Estas são apenas estimativas usadas para fins de escolha interna do plano; eles geralmente não refletem o desempenho do mundo real em hardware moderno e nunca são nada além de uma estimativa - mesmo em um plano de execução pós-execução ("real").
No estúdio de gerenciamento:
No SQL Sentry Plan Explorer :
Não, isso significa que 24 threads paralelos cooperaram para realizar uma única varredura da tabela heap. Cada thread ainda lê uma linha por vez da varredura, executa uma busca na tabela indexada, obtém a próxima linha da varredura e assim por diante até que a tarefa seja concluída.
As linhas não são lidas em lotes e armazenadas na memória neste plano. O SQL Server relata 24 verificações porque cada 24 threads executaram uma verificação parcial da tabela, resultando em uma verificação completa geral.
As propriedades
ForceScan,ForceSeekeForcedIndexsão definidas como true se a consulta especificar umFORCESCAN,FORCESEEKouINDEXdica - ou se o otimizador de consulta decidir que uma estratégia de acesso específica é necessária para correção (por exemplo, ao verificar restrições de chave estrangeira).