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

Estimativas de cardinalidade ruins dos planos do SSMS – redux


Há mais de três anos, publiquei uma correção no Plan Explorer sobre estimativas de cardinalidade ruins que o Showplan XML do SQL Server estava produzindo, no caso de pesquisas de chave/RID com um predicado de filtro no SQL Server 2008 e superior. Achei que seria interessante olhar para trás e detalhar um pouco mais um desses planos e as iterações pelas quais passamos para garantir que estávamos exibindo as métricas corretas, independentemente do que o Management Studio mostra. Novamente, este trabalho foi feito em grande parte por Brooke Philpott (@MacroMullet) e Greg Gonzalez (@SQLsensei) e com grande contribuição de Paul White (@SQL_Kiwi).



Isso é bastante semelhante à consulta que apresentei no meu post anterior, que veio de Paul (e que daria algum trabalho para reproduzir exatamente nas versões modernas do AdventureWorks, onde pelo menos as datas de transação foram alteradas):
SELECT
    th.ProductID,
    p.Name,
    th.TransactionID,
    th.TransactionDate
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
    th.ProductID = p.ProductID
WHERE 
    p.ProductID IN (1, 2)
    AND th.TransactionDate BETWEEN '20070901' AND '20071231';

O plano do Management Studio parecia correto o suficiente:



No entanto, se você olhar mais de perto, parece que o ShowPlan empurrou o número estimado de execuções da pesquisa de chave diretamente para o número estimado de linhas para a troca final:



À primeira vista, o diagrama de plano gráfico no Plan Explorer é bastante semelhante ao plano que o SSMS produz:



Agora, no processo de desenvolvimento do Plan Explorer, descobrimos vários casos em que o ShowPlan não acerta em sua matemática. O exemplo mais óbvio são as porcentagens que somam mais de 100%; acertamos nos casos em que o SSMS está ridiculamente desligado (vejo isso com menos frequência hoje do que costumava, mas ainda acontece).

Outro caso é onde, a partir do SQL Server 2008, o SSMS começou a colocar o total de linhas estimadas em vez de linhas por execução junto com pesquisas, mas apenas nos casos em que um predicado é enviado para a pesquisa (como o caso neste bug relatado por Paul, e esta observação mais recente de Joey D'Antoni). Em versões anteriores do SQL Server (e com funções e spools), normalmente mostraríamos as contagens de linhas estimadas provenientes de uma pesquisa multiplicando as linhas estimadas por execução (geralmente 1) pelo número estimado de linhas de acordo com o SSMS. Mas com essa mudança, estaríamos contando em excesso, já que o operador já está fazendo essa matemática. Portanto, em versões anteriores do Plan Explorer, em relação a 2008+, você veria esses detalhes nas dicas de ferramentas, linhas de conexão ou nas várias grades:



(De onde vem 1.721? 67,5 execuções estimadas x 25,4927 linhas estimadas.)

Em 2012, corrigimos parte desse problema deixando de realizar essa operação matemática e confiando apenas nas contagens de linhas estimadas provenientes da pesquisa de chave. Isso estava quase correto, mas ainda estávamos contando com a contagem de linhas estimada que o ShowPlan estava nos fornecendo para a troca final:



Também resolvemos esse problema rapidamente, na versão 7.2.42.0 (lançada no Hallowe'en 2012), e agora sentimos que estamos fornecendo informações muito mais precisas do que o Management Studio (embora fiquemos de olho nesse bug de Paul) :



Isso claramente aconteceu há muito tempo, mas eu ainda achei que seria interessante compartilhar. Continuamos a fazer melhorias no Plan Explorer para fornecer as informações mais precisas possíveis, e compartilharei mais algumas dessas pepitas nas próximas postagens.

No