Início / dba / Perguntas / 345430
Accepted
nam
Asked: 2025-02-25 10:01:28 +0800 CST

Por que a função SUM retorna 4 casas decimais, mas a função AVG retorna 6 casas decimais

  • 772

Pergunta : Por que SUMo retorno é com 4 casas decimais (como esperado), mas o Avgretorno é com 6 casas decimais?

CREATE TABLE #t(Col DECIMAL(19,4))
INSERT #t VALUES (123456.1200),(654321.3400)
SELECT SUM(Col), AVG(Col) FROM #t
SomaQuantia Valor médio
777777.4600 388888.730000

Observações : Observe que a questão NÃO é sobre como podemos exibir AverageAmountcom 4 decimais, mas por que AverageAmountestá retornando com 6 casas decimais. Isso é um bug ou há algum motivo válido por trás disso? Estou usando a versão mais recente do SQL Server 2022 no Windows 11

sql-server

2 respostas

  1. Best Answer

    O tipo de dados de SUM(Col)é DECIMAL(38,4).

    O que faz sentido, já que adicionar DECIMAL(x,4)nunca pode aumentar a escala necessária. 4 casas decimais sempre serão suficientes (e permitir uma precisão de 38maximiza o número de elementos que podem ser adicionados antes de ocorrer um estouro).

    Em seguida, ele AVG(Col)pega esse DECIMAL(38,4)resultado e realiza uma operação de divisão nele.

    CASE WHEN COUNT_BIG(Col) = 0 THEN NULL ELSE SUM(Col)/COUNT_BIG(Col) END

    COUNT_BIGé um , BIGINTentão tem uma precisão de 19e escala de 0.

    Você pode ver isso com

    SET SHOWPLAN_TEXT ON

GO

SELECT AVG(Col)  FROM #t

    Que retorna

    |--Compute Scalar(DEFINE:([Expr1003]=CASE WHEN [Expr1004]=(0) THEN NULL ELSE [Expr1005]/CONVERT_IMPLICIT(decimal(19,0),[Expr1004],0) END))
    |--Stream Aggregate(DEFINE:([Expr1004]=COUNT_BIG([#t].[Col]), [Expr1005]=SUM([#t].[Col])))
        |--Table Scan(OBJECT:([tempdb].[dbo].[#t]))

    O resultado desta divisão teria um tipo de dado hipotético de acordo decimal(58,24) com as regras aqui

    DECLARE @p1 int = 38, @s1 int = 4,
        @p2 int = 19, @s2 int = 0;

SELECT @p1 - @s1 + @s2 + greatest(6, @s1 + @p2 + 1),
       greatest(6, @s1 + @p2 + 1)

    Mas esse tipo de dado não é possível, pois a precisão máxima é 38e você atinge a regra mais abaixo

    A escala é definida como 6 se for maior que 6 e se a parte integral for maior que 32. Nesse caso, tanto a parte integral quanto a escala seriam reduzidas e o tipo resultante seria decimal(38, 6)

    Uma expansão completa dessas regras de truncamento está abaixo.

    DECLARE @p1 int = 38, @s1 int = 4,
        @p2 int = 19, @s2 int = 0,
        @p_new int  , @s_new int = 0;

SELECT @p_new = @p1 - @s1 + @s2 + greatest(6, @s1 + @p2 + 1),
       @s_new = greatest(6, @s1 + @p2 + 1)

IF @p_new > 38
BEGIN
DECLARE @integral_part INT = @p_new - @s_new;

IF @integral_part < 32
    BEGIN
    --Multiplication/ Division truncation rule 1
    SELECT @s_new = least(@s_new, 38 - (@integral_part)) 
    SELECT @p_new = @s_new + @integral_part
    END
ELSE
    --Multiplication/ Division truncation rules 2 and 3
     SELECT @p_new = 38, @s_new = least(@s_new, 6);
END

SELECT CONCAT('(',@p_new,',',@s_new,')') AS [(p,s)]

    Para qualquer decimalespecificação @p1, @p2, e @s2sempre tem o mesmo valor que o SUMde decimalsempre tem precisão 38, e sempre será dividido por bigint. Tentar valores diferentes de @s1mostra que o resultado é de fato sempredecimal(38, greatest(s,6))

    • 14

  2. https://learn.microsoft.com/en-us/sql/t-sql/functions/avg-transact-sql?view=sql-server-ver16

    AVG em decimais(p,s) resulta no tipo decimal(38, max(s,6))

    SOMA em decimal(p,s) resulta em decimal(38,s)

    Então não é um bug, é apenas a maneira como funciona.

    • 3

relate perguntas