为什么当我们使用SMALLINT而不是DECIMAL时SUM更快

Question

Are there any known rules saying some T-SQL types are better for calculations?

I have two identical tables containing numbers - one with SMALLINT fields and second with DECIMAL(9,2) fields. I am performing the following operations over them (two queries):

SUM(CAST(A AS BIGINT))
SUM(CAST(A AS BIGINT))
CAST(CAST(SUM(A) AS decimal) / CASE SUM(B) WHEN 0 THEN NULL ELSE SUM(B) END * 100 AS decimal(18, 0))
CAST(CAST(SUM(A) AS decimal) / CASE SUM(B) WHEN 0 THEN NULL ELSE SUM(B) END * 100 AS decimal(18, 1)) 

SUM(CAST(A AS DECIMAL(19,2))) 
SUM(CAST(A AS DECIMAL(19,2)))
CAST(SUM(CAST([A] AS DECIMAL(19, 2))) / IIF(SUM(CAST([B] AS DECIMAL(19, 2))) = 0, NULL, SUM(CAST([B] AS DECIMAL(19, 2)))) * 100 AS DECIMAL(19, 0))
CAST(SUM(CAST([A] AS DECIMAL(19, 2))) / IIF(SUM(CAST([B] AS DECIMAL(19, 2))) = 0, NULL, SUM(CAST([B] AS DECIMAL(19, 2)))) * 100 AS DECIMAL(19, 1))

and there the query results are about:

• 29 seconds for the table with decimal columns
• 18 seconds for the table with smallint columns

The only difference is in the byes for each type:

• smallint is 2 bytes
• decimal(9,2) is 5 bytes

Is this the reason SMALLINT is faster then DECIMAL(9,2) for such operations?

Note: I have the same values in each tables - I have not got decimal numbers - only whole numbers.

Answer 1

Yes, that's true. Smallint values need less space on disk and the IO operation have much more performance. It's always a good idea to have as 'small' type as it is possible.

Answer 2

From Microsoft's documentation :

Converting from decimal or numeric to float or real can cause some loss of precision. Converting from int, smallint, tinyint, float, real, money, or smallmoney to either decimal or numeric can cause overflow.

By default, SQL Server uses rounding when converting a number to a decimal or numeric value with a lower precision and scale. However, if the SET ARITHABORT option is ON, SQL Server raises an error when overflow occurs. Loss of only precision and scale is not sufficient to raise an error.

This strongly implies that extra operations surround decimal arithmetic, specifically scaling, rounding, and range checking. All of those are substantially harder (more computation intensive) than addition, especially on an x86 CPU.

The fastest datatypes are those native to the CPU—usually char and integer — and should be fastest on most SQL platforms.