Quando eu tenho 6 núcleos e eles fazem uma varredura de tabela e mesclam depois, cada núcleo varre toda a tabela?

Para ser franco com você, não tenho certeza do que você quer dizer com "uma fusão foi feita". Você está falando sobre uma junção de mesclagem? Talvez você queira dizer um operador de paralelismo? No mínimo, posso responder à pergunta sobre varreduras de tabelas paralelas.

As estatísticas de IO me mostraram que cada núcleo fez uma varredura de tabela, ou melhor, fiz 6 varreduras de tabela.

Suponho que o que você quer dizer com isso é que você executou SET STATISTICS IO ONantes de executar sua consulta e parte da saída incluiu algo assim:

Tabela 'sua_tabela'. Contagem de digitalização 6, ...

O rótulo "contagem de varredura" é um pouco enganador. Você não deve concluir que, se STATISTICS IOrelatadas 6 verificações, todas as linhas da tabela foram verificadas 6 vezes. Considerando o seguinte exemplo simples de consulta em uma tabela heap chamada heap_table:

SELECT TOP 1 *
FROM heap_table
OPTION (MAXDOP 1);

Para essa consulta STATISTICS IO, deve relatar uma contagem de varredura de 1, certo? Mas o SQL Server claramente não precisava ler todas as linhas da tabela. Observar a definição do rótulo de contagem de varredura também é útil:

Número de buscas/varreduras iniciadas após atingir o nível folha em qualquer direção para recuperar todos os valores para construir o conjunto de dados final para a saída.

...

A contagem de varredura é N quando N é o número de diferentes buscas/varreduras iniciadas no lado esquerdo ou direito no nível folha após localizar um valor de chave usando a chave de índice.

Portanto, se sua consulta fez uma varredura paralela, eu esperaria ver uma contagem de varredura de pelo menos 6, mas isso não implica necessariamente que todas as linhas da tabela foram lidas seis vezes. Como você pode saber como as linhas foram distribuídas entre os núcleos da CPU?

A maneira mais fácil é apenas olhar para um plano de execução real. Se você observar os detalhes de uma verificação paralela, o SQL Server mostrará quantas linhas foram processadas por cada thread da CPU. Abaixo está uma imagem do que você pode ver emprestado do artigo de Paul White Planos de Execução Paralela – Ramos e Threads :

Como você disse, encontrou essa consulta anos atrás, então esse método não o ajudará. Em vez disso, precisamos examinar as técnicas disponíveis para o SQL Server para processamento de planos paralelos. Craig Freedman tem uma série de postagens de blog sobre o assunto. Do artigo Parallel Scan :

Como funciona a varredura paralela?

Os threads que compõem uma verificação paralela trabalham juntos para verificar todas as linhas em uma tabela. Não há nenhuma atribuição a priori ou linhas ou páginas para um segmento específico. Em vez disso, o mecanismo de armazenamento distribui dinamicamente páginas para threads. Um fornecedor de páginas paralelas coordena o acesso às páginas da tabela. O fornecedor de páginas paralelas garante que cada página seja atribuída a exatamente um thread e, portanto, seja processada exatamente uma vez.

Bem, aí está. Como eu disse anteriormente, você pode testar isso facilmente executando uma consulta com uma verificação paralela e verificando os detalhes do operador de verificação paralela no plano de execução real.

Para ver isso de outra maneira, tente pensar em um cenário em que seja benéfico para o SQL Server fazer uma verificação completa da tabela por núcleo.

Suponha que você tenha uma UNION ALLconsulta que referencia sua tabela seis vezes. Em princípio, o SQL Server poderia fazer cada varredura de tabela com um núcleo de forma independente e combinar os resultados no final. No entanto, o SQL Server não fará isso porque não fará paralelismo de pipeline . Mesmo que pudesse, pessoalmente não consigo pensar em nenhuma vantagem em fazer isso aqui, além de evitar parte da sobrecarga associada ao paralelismo.

Você poderia ler sobre o tipo de transmissão paralela de execução e se perguntar se nesse cenário o SQL Server poderia fazer seis verificações completas de uma tabela, uma com cada núcleo. Para o tipo de transmissão de troca, o SQL Server envia todas as linhas para todos os threads do consumidor. No entanto, isso pode ser feito com uma varredura serial na tabela seguida por um tipo de troca paralela Distribute Streams . Na verdade, isso é o que você vê no exemplo de hash join. Não consigo pensar em nenhum benefício em fazer essa varredura em paralelo, especialmente quando o tipo de transmissão é usado apenas para tabelas relativamente pequenas.

Um caso em que suponho que isso poderia acontecer é se você tivesse uma junção de loop aninhado paralelo com uma tabela externa que continha 6 linhas e com uma varredura de tabela no lado interno da junção. Nesse caso, acredito que as varreduras de tabela serão concluídas por encadeamentos seriais independentes, de modo que cada núcleo faça sua própria varredura de tabela. É claro que essa consulta provavelmente terá um desempenho muito ruim e não é algo a ser almejado, especialmente quando a tabela externa tem mais de seis linhas.