POWER / LOG的问题在于，尽管它们似乎适应了您发送的数据类型（输出变量类型与第一个变量的类型匹配），但精度似乎停在浮点数的极限附近，导致输出错误。 示例：
DECLARE @ten numeric(18,4) = 10
declare @num numeric(18,4) = 234567890
SELECT power(@ten,log(@num,@ten))
输出= 234567890.0000 哪个是正确的
但是，如果我们提高精度，则如下：
DECLARE @ten numeric(18,6) = 10
declare @num numeric(18,6) = 234567890
SELECT power(@ten,log(@num,@ten))
输出= 234567889.999999 哪一个是不正确的，但是四舍五入可以解决它（？）
最后，如果将精度更改为Numeric（18,9）之类的问题，问题将变得更加严重：
DECLARE @ten numeric(18,9) = 10
declare @num numeric(18,9) = 234567890
SELECT power(@ten,log(@num,@ten))
输出= 234567889.999999310 这是不正确的，四舍五入不能解决问题。
我假设问题是，尽管POWER和Log函数可以接受非常精确的数据类型，但是它们的工作变量必须是浮点类型吗？是否有人对此有任何经验，或者有解决此问题的经验？
答案 0 :(得分：3)
我认为问题在于LOG的返回类型是FLOAT，而不是您传递的数据类型。FLOAT是用于浮点数的近似数字数据类型数字数据。浮点数据是近似值；因此，并非所有数据类型范围内的值都可以准确表示出来。
另一方面，POWER接受类型为float或可以隐式转换为float的类型的表达式。作为输入，并返回依赖的类型关于float表达式的输入类型。意思是，它将为输入DECIMAL返回DECIMAL。
因此，在您的情况下，LOG返回的FLOAT传递到POWER中，而返回的FLOAT并不精确。
答案 1 :(得分：3)
这个评论太长了。
可以使用两种不同的方式处理非整数的交易：使用定点算法或浮点算法。两种方法都会引入错误。
log()函数被记录为接受float作为参数并返回float。 power()的行为有所不同。第一个参数转换为float，但它也确定返回类型。这就是为什么返回类型的比例受@ten的比例驱动的原因。
所有发生的事情是您看到的是不同刻度的完全相同的值。数字略有不足为奇-舍入问题是计算机上非整数算法的已知问题。
一点也不奇怪。 234567889.9999993145465850830是所产生的价值。这是SQL Server最接近实际答案的地方-并且足够接近进行大多数工作。