“Avisos: a operação causou E / S residual” versus pesquisas principais

Eu vi esse aviso nos planos de execução do SQL Server 2017:

Avisos: A operação causou IO residual [sic]. O número real de linhas lidas foi (3,321,318), mas o número de linhas retornadas foi 40.

Aqui está um trecho do SQLSentry PlanExplorer:

Para melhorar o código, adicionei um índice não clusterizado, para que o SQL Server possa acessar as linhas relevantes. Funciona bem, mas normalmente haveria colunas (grandes) demais para serem incluídas no índice. Se parece com isso:

Se eu adicionar apenas o índice, sem incluir colunas, ficará assim, se forçar o uso do índice:

Obviamente, o SQL Server acha que a pesquisa de chave é muito mais cara que a E / S residual. Eu tenho uma configuração de teste sem muitos dados de teste (ainda), mas quando o código entra em produção, ele precisa trabalhar com muito mais dados, por isso tenho certeza de que é necessário algum tipo de índice não clusterizado.

As pesquisas principais são realmente tão caras , quando você executa SSDs, que preciso criar índices completos (com muitas colunas de inclusão)?

Plano de execução: https://www.brentozar.com/pastetheplan/?id=SJtiRte2X Faz parte de um longo procedimento armazenado. Procure IX_BatchNo_DeviceNo_CreatedUTC.

O modelo de custo usado pelo otimizador é exatamente isso: um modelo . Geralmente, produz bons resultados em uma ampla variedade de cargas de trabalho, em uma ampla variedade de designs de banco de dados, em uma ampla variedade de hardware.

Geralmente, você não deve assumir que as estimativas de custo individuais se correlacionam fortemente com o desempenho do tempo de execução em uma configuração de hardware específica. O objetivo do cálculo de custos é permitir que o otimizador faça uma escolha instruída entre alternativas físicas candidatas para a mesma operação lógica.

Quando você realmente entra em detalhes, um profissional de banco de dados qualificado (com tempo de sobra para ajustar uma consulta importante) geralmente pode se sair melhor. Nessa medida, você pode pensar na seleção do plano do otimizador como um bom ponto de partida. Na maioria dos casos, esse ponto de partida também será o ponto final, pois a solução encontrada é boa o suficiente .

Na minha experiência (e opinião), o otimizador de consultas do SQL Server custa pesquisas mais altas do que eu preferiria. Essa é uma grande ressaca dos dias em que a E / S física aleatória era muito mais cara em comparação com o acesso seqüencial do que costuma acontecer hoje.

Ainda assim, as pesquisas podem ser caras, mesmo em SSDs, ou mesmo na leitura exclusiva da memória. Atravessar estruturas de árvores b não é de graça. Obviamente, o custo aumenta à medida que você faz mais deles.

As colunas incluídas são ótimas para cargas de trabalho OLTP pesadas para leitura, onde a troca entre uso de espaço de índice e custo de atualização versus desempenho de leitura em tempo de execução faz sentido. Há também uma compensação a considerar em torno da estabilidade do plano . Um índice de cobertura total evita a questão de quando exatamente o modelo de custo do otimizador pode fazer a transição de uma alternativa para outra.

Somente você pode decidir se as compensações valem a pena no seu caso. Teste as duas alternativas em uma amostra de dados representativa e faça uma escolha informada.

Em um comentário de pergunta, você adicionou:

Você está me dizendo que o SQL Server não sabe o custo do IO residual?

Não, o otimizador considera o custo de E / S residual. De fato, no que diz respeito ao otimizador, os predicados não SARGable são avaliados em um filtro separado. Esse filtro é empurrado para a busca ou verificação como um resíduo durante as reescritas pós-otimização .