Início / dba / Perguntas / 216879
Accepted
James D
Asked: 2018-09-07 01:01:28 +0800 CST

Serialização forçada na função com valor de tabela inline

  • 772

Desculpe se esta é uma pergunta estúpida. Estamos tentando converter nossas funções com valor de tabela de várias instruções (MSTVFs) em funções com valor de tabela em linha (ITVFs), para evitar a serialização forçada de consultas.

Eu tenho a seguinte função ITVF (diluída), mas o Plano de Execução ainda diz que tem um Grau de Paralelismo de 1. A função real em questão tem três instruções SELECT básicas separadas por UNION ALLs.

Eu perdi alguma coisa? Como posso evitar a serialização forçada aqui?

CREATE FUNCTION dbo.Test (@i int)
RETURNS TABLE
AS
RETURN
SELECT @i as [i];
GO

SELECT * FROM dbo.Test (2);
GO

https://www.brentozar.com/pastetheplan/?id=Hyn8o50D7

A instância tem as seguintes configurações:

  • Limite de custo para paralelismo = 5
  • Grau Máximo de Paralelismo = 0
sql-server t-sql

1 respostas

  1. Best Answer

    Simplesmente, sua consulta não tem um custo estimado alto o suficiente.

    O SQL Server estima quanto esforço uma consulta exigirá e revela essa medida sem unidade como custo estimado. Se estiver abaixo do seu limite de custo para paralelismo, o SQL Server não se incomodará com um plano paralelo. Seu plano tem um custo estimado de 0,129, o que, por ser menor que 5, significa que não há paralelismo.

    Também no XML do seu plano está o detalhe de que essa consulta levou apenas 1 milissegundo. Você não precisa ir em paralelo. Não há trabalho suficiente para justificar a sobrecarga de distribuir o esforço entre vários threads.

    Como um aparte para uma versão anterior desta pergunta, mesmo as consultas que seriam TRIVIAIS serão paralelas se o custo estimado for alto o suficiente e todas as outras condições para o paralelismo forem atendidas.

    Uma forma de provar que algo está impedindo o paralelismo está NonParallelPlanReason="CouldNotGenerateValidParallelPlan"no plano XML.

    Outra maneira de testar (suponho que você esteja no SQL Server 2014, porque 2016 tem uma dica real a ser usada) é adicionar OPTION(QUERYTRACEON 8649)à sua consulta. Por favor, apenas use isso para testar, porque adicionar sinalizadores de rastreamento não documentados ao código de produção é realmente estúpido , não é uma coisa boa.

    • 5

relate perguntas