leituras lógicas x contagem de varreduras

Estou ingressando em uma tabela pequena (1.000 linhas) em uma tabela grande (8M linhas) no SQL Server 2008. A associação usa um índice de cobertura não clusterizado na tabela grande e a associação pode produzir três possíveis planos de consulta. Estou tentando descobrir qual plano é melhor, mas também quero generalizar esse conhecimento para que da próxima vez eu possa saber melhor quais heurísticas usar ao analisar as estatísticas de E / S do SQL.

O plano 1 é uma junção de loop e emite estatísticas para a tabela grande como esta:

Scan count 2582, logical reads 35686, physical reads 1041, read-ahead reads 23052

O plano 2 é uma junção de mesclagem e emite estatísticas como esta:

Scan count 1, logical reads 59034, physical reads 49, read-ahead reads 59004

O plano 3 é uma junção de hash e emite estatísticas como esta:

Scan count 3, logical reads 59011, physical reads 5, read-ahead reads 59010

O índice de cobertura é ordenado por (ID, Date). A consulta retorna dados para cerca de 50% dos IDs e, para cada ID, retorna um pedaço contíguo dos três meses mais recentes de dados, que geralmente é de cerca de 1/4 ou das linhas para cada ID. A consulta retorna cerca de 1/8 do total de linhas no índice. Em outras palavras, a consulta é esparsa, mas consistente.

Suponho que o plano 1 seja péssimo para essa carga de trabalho, porque mover a cabeça do disco cerca de 2.500 vezes (ou até 1.041 vezes) é muito mais caro do que uma varredura seqüencial de disco. Também presumo que os nºs 3 e 2 tenham padrões de E / S semelhantes e sequenciais (e, portanto, mais eficientes).

Mas existe um caso em que o plano nº 1 é realmente melhor, em que "melhor" significa menos impacto no subsistema de E / S e menos impacto em outras consultas em execução simultaneamente?

Ou realmente depende de muitas variáveis, como o tipo de subsistema de disco que tenho, fragmentação de índice etc. Se "depende", existem regras práticas para abordar o problema?

Aqui está o grande negócio: em janeiro, estava custando US $ 12 mil para comprar 864 * GB * de RAM . Você pode obter muitas vantagens, simplesmente aumentando a RAM do seu servidor até o ponto em que você nunca obterá uma leitura física (após o aquecimento, é claro).

Fora isso, é realmente difícil dar uma opinião em preto e branco sobre qualquer um desses pontos de dados que você apresenta. Certamente, o plano nº 1 teve a maioria das leituras físicas, mas você está certo de que todos os testes foram feitos no cache aquecido da mesma forma? Será que o nº 1 aqueceu o cache do nº 2, qual é a sua metodologia de teste para garantir que todos os casos sejam considerados em nível nivelado? Mesmo assim, se você desembolsar US $ 500 e duplicar a RAM, isso importaria mais? O número 1 tem as leituras menos lógicas ...

Mas o número 2 provavelmente se beneficia de um DOP alto (que uma verificação pode ser paralela). O tempo do relógio de parede nº 2 é melhor que o nº 1 depois de adicionar RAM suficiente?

Quantos desses planos são executados em paralelo? Existem dezenas de consultas solicitando simultaneamente uma concessão de memória significativa para o hash nº 3 e, assim, criando contenção para o RESOURCE_SEMAPHORE? O nº 2 está fazendo uma classificação e também solicitando uma concessão de memória? O item 1 funcionará melhor, pois não requer concessão (pelo menos a partir das informações postadas ...)?

É realmente muito relativo e a pergunta que você faz é mais como encontrar uma solução para um sistema complexo de equações ... simplesmente poderia haver mais de uma solução.

Uma coisa é certa: linhas de 8 milhões devem caber na RAM com bastante espaço de sobra. Essas leituras físicas estão implorando por alguns bancos de memória.

Para essa consulta aparentemente muito simples, o otimizador produzirá consistentemente o melhor plano de acordo com seu modelo de custo. O modelo de custo é bastante preciso. Portanto, minha recomendação seria deixar a opção para o SQL Server.

Segunda recomendação: avalie a duração da consulta para todas as três variantes com um hot cache. Então decida. (Não decida com base em leituras, digitalizações e coisas assim. O que importa para você é a duração.)

Em geral, para escolher o melhor tipo (ou índices) de junção, é necessário entender como os algoritmos de junção funcionam. É muita informação para postar aqui.

Ignorar contagem de varredura, isso não é importante. Concentre-se em como diminuir as leituras lógicas. Com base em http://www.practicalsqldba.com/2013/07/sql-server-performance-tuning.html .