我正在为一个项目处理一些SQL，但是我注意到在SQL Server中一些看似奇怪的行为，即用小数除法得到的答案是什么样的。

以下是一些示例，这些示例说明了我所看到的行为：

DECLARE @Ratio Decimal(38,16)
SET @Ratio = CAST(210 as Decimal(38,16))/CAST(222 as Decimal(38,16));

select @Ratio -- Results in 0.9459450000000000

DECLARE @Ratio Decimal(38,16)
SET @Ratio = CAST(210 as Decimal)/CAST(222 as Decimal);

select @Ratio -- Results in 0.9459459459459459

对于上面的代码，（似乎）不太精确的查询答案给出了更精确的值作为答案。当我同时将被除数和除数都设置为时Decimal(38,16)，我得到一个小数位数为6的数字（将其转换为a会Decimal(38,16)导致0填充小数位数）。

当我将除数和除数仅转换为默认的十进制，而没有手动设置精度或小数位数时，我得到的结果小数位数全为16位。

出于好奇，我开始使用以下查询对它进行更多的实验：

select CAST(210 as Decimal(38,16))/CAST(222 as Decimal(38,16)) --0.945945
select CAST(210 as Decimal(28,16))/CAST(222 as Decimal(28,16)) --0.9459459459
select CAST(210 as Decimal(29,16))/CAST(222 as Decimal(29,16)) --0.945945945

如您所见，随着我提高精度，答案的规模似乎减小了。我看不到结果的规模与被除数和除数的规模或精度之间的相关性。

我发现了一些其他问题，这些问题指向msdn文档中的某个位置，该位置指出通过对除数和除数的精度和小数位数进行一组计算，可以确定对小数进行运算时得到的精度和小数位数，并且：

结果精度和小数位的绝对最大值为38。当结果精度大于38时，相应的小数位会减小，以防止结果的整数部分被截断。

因此，我自己尝试遍历这些方程式，以确定将aDecimal(38,16)分解为另一个的Decimal(38,16)结果，根据我的发现，我仍然应该获得比我更精确的数字。

所以我做错了数学，或者这是我所缺少的其他事情。非常感谢您提供的任何见解。

提前致谢…