SSMS
 sql >> Base de Dados >  >> Database Tools >> SSMS

Estimativas de cardinalidade ruins provenientes de planos de execução do SSMS


Tenho algumas pessoas a agradecer por uma atualização recente do SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) e Greg Gonzalez (blog | @SQLsensei), é claro, para pesquisa e desenvolvimento e para investigar o código e resolvê-lo. Mas também a Paul White (blog | @SQL_kiwi) por ser persistente em nos ajudar a validar as correções.

O problema que Paul descobriu é que o SQL Server 2008+ atrapalha as estimativas de cardinalidade em determinadas consultas quando pesquisas de chave ou RID estão envolvidas. Vou deixar a explicação mais profunda para a postagem do blog de Paul e o bug que ele registrou no Connect, mas para encurtar a história, estávamos pegando essas estimativas deturpadas, acreditando nelas e extrapolando-as para mostrar informações "melhores". Infelizmente, como explica Paul, fomos enganados.

Paul mostra a seguinte consulta em uma cópia do AdventureWorks 2005.
SELECT
    th.ProductID,
    th.TransactionID,
    th.TransactionDate
FROM Production.TransactionHistory AS th 
WHERE 
    th.ProductID = 1 
    AND th.TransactionDate BETWEEN '20030901' AND '20031231';

O Management Studio produz o seguinte plano, exatamente como Paul o descreveu:



No Plan Explorer, tentamos ser úteis multiplicando o número estimado de linhas (arredondado para 17) pelo número de execuções (45) e chegamos a 765:



Para a maioria dos operadores, essa abordagem produz os dados corretos, mas devido a esse bug no SQL Server, ela não é correta para pesquisas de chave/RID. Ajustamos para isso e lançamos a correção apropriada na versão 7.2.42.0 (faça o download agora!). O plano gráfico agora mostra corretamente as contagens de linhas para ambas as estimativas:



E real:



Vou repetir o aviso de Paul:Cuidado com estimativas de cardinalidade ruins quando um predicado é aplicado como parte de uma pesquisa.

Houve alguns problemas mais complexos causados ​​por essas estimativas enganosas, que também abordamos. Vou escrever sobre alguns deles em um post de acompanhamento – para este post eu só queria demonstrar que resolvemos rapidamente o problema específico que Paul destacou em seu post.