Estou testando no SQL Server 2019 CU14. Eu tenho uma consulta de modo de linha pura que seleciona as 50 principais linhas de uma visualização complicada. A consulta completa leva 25.426 ms de tempo de CPU em MAXDOP 1 e 19.068 ms de tempo de CPU em MAXDOP 2. Não estou surpreso que a consulta paralela use menos tempo de CPU em geral. A consulta paralela é elegível para operadores de bitmap e o plano de consulta é diferente em alguns aspectos. No entanto, estou surpreso com uma grande diferença relatada nos tempos de operação para a classificação N superior.
No plano serial, é relatado que a classificação N superior levou cerca de 10 segundos de tempo de CPU pelas estatísticas de execução do operador:
O plano MAXDOP 2 relata cerca de 1,6 segundos de tempo de CPU para a mesma classificação N superior:
Não entendo por que uma diferença tão grande é relatada entre os dois planos de consulta diferentes. Os escalares de computação no operador pai são muito simples e não podem explicar a discrepância nos tempos do operador. Aqui está como eles se parecem:
[Expr1055] = Scalar Operator(CASE WHEN COLUMN_1 IS NULL THEN (0) ELSE datediff(day,COLUMN_1,getdate()) END),
[Expr1074] = Scalar Operator(CASE WHEN [Expr1074] IS NULL THEN (0) ELSE [Expr1074] END)
Existem outros escalares de computação em diferentes partes do plano. Carreguei planos reais anônimos para o plano serial e o plano paralelo, se alguém quiser revisá-los.
Quando carrego os resultados completos da consulta sem TOP em uma tabela temporária e executo uma classificação TOP 50 na tabela temporária, tanto o plano paralelo quanto o serial levam cerca de 1200 ms de tempo de CPU para executar a classificação. Portanto, o tempo do operador relatado para a classificação paralela na consulta completa parece razoável para mim. Os dez segundos para a consulta serial não.
Por que a classificação serial top N tem um tempo de CPU relatado muito maior do que a classificação paralela? É realmente muito menos eficiente ou isso pode ser um bug com as estatísticas de execução da operação?
É difícil ter certeza com base em um plano anônimo sem uma reprodução, mas o primeiro mecanismo que vem à mente é a avaliação de expressão diferida .
No plano serial , o Sort pode ser responsável por avaliar um grande número de expressões adiadas de operadores anteriores. Isso inclui valores que devem ser materializados naquele ponto nos buffers de classificação, não apenas chaves de classificação. O custo de avaliação das expressões é, portanto, suportado pelo Sort.
No plano paralelo , essas expressões podem ter que ser avaliadas anteriormente, por exemplo, quando os valores devem ser materializados em buffers de troca em operadores de Paralelismo . O custo da avaliação da expressão é distribuído entre as operadoras do plano e não concentrado no Sort .
Há um grande número de expressões (Exprxxxx) no Sort . Uma seleção é mostrada abaixo (eles não caberiam em uma única captura de tela):
Não tentei rastrear qual deles pode ser o responsável porque o tamanho e a natureza anônima do plano tornam isso inviável.
Existem muitos operadores que podem definir expressões, não apenas Compute Scalar . Citando meu artigo vinculado anteriormente:
A avaliação da expressão pode ser adiada por um longo tempo, em muitos operadores. O ponto chave é que a avaliação é adiada até que o resultado da expressão seja necessário por outro operador, ou até mesmo até que o servidor precise montar linhas para retornar ao cliente. Os operadores de bloqueio ou semibloqueio são apenas um exemplo em que a avaliação da expressão pode precisar ser materializada.
Os usuários de outras línguas podem estar familiarizados com o conceito sob o nome de 'avaliação preguiçosa'. A computação é adiada pelo tempo que for logicamente possível.
Naturalmente, materializar os resultados em uma tabela temporária significa que todas as expressões são avaliadas. Isso explica por que você vê os tempos de CPU esperados para execução da origem da tabela temporária.