浮点数精度丢失是必然的，因POWER/SQRT默认使用FLOAT/DOUBLE，而0.1等十进制小数在二进制中无限循环，导致表示与运算误差；金融或科学计算必须全程显式CAST为DECIMAL并控制类型、精度与舍入。
直接用 POWER 和 SQRT 做金融或科学计算，精度丢失不是“可能”，而是“必然”——它们默认按 FLOAT 或 DOUBLE 计算，而浮点数的二进制表示根本存不准 0.1、0.01 这类十进制小数。
为什么 POWER(x, y) 和 SQRT(x) 默认精度失控
这两个函数在几乎所有主流数据库（SQL Server、MySQL、PostgreSQL）中，输入未显式指定类型时，会隐式转为 FLOAT 或 DOUBLE。比如 POWER(1.05, 365) 看似是复利计算，实际参与运算的是近似值 1.0499999999999998，误差经 365 次幂后被指数级放大。
-
SQRT对整数输入也返回FLOAT，例如SQRT(25)返回5.0而非精确整数；后续做= 5判断可能因尾部浮点噪声失败 -
POWER(x, 0.5)比SQRT(x)更危险：它不校验负数，POWER(-4, 0.5)在 SQL Server 中静默返回NULL，在 MySQL 中直接报错，行为不一致 - 嵌套使用如
SQRT(POWER(x, 2))，中间结果先转FLOAT再开方，原始INT的精度已不可逆丢失
必须显式 CAST 所有参与运算的值和函数结果
别依赖“看起来对”，金融、物理建模要求每一步都可控。所有数值字段、参数、临时变量、函数返回值，只要涉及精度敏感场景，必须强制声明为 DECIMAL 并立刻包裹。
- 写成
CAST(POWER(CAST(x AS DECIMAL(38,12)), 0.5) AS DECIMAL(38,12))，而不是裸写POWER(x, 0.5) - 对输入列提前转换：
SQRT(CAST(price AS DECIMAL(18,6)))，避免从INT→FLOAT→FLOAT的双重漂移 - 存储过程中定义参数时就用
@rate DECIMAL(18,6)，别用@rate FLOAT - 注意：SQL Server 的
POWER(DECIMAL, FLOAT)仍会降级为FLOAT，所以指数也得是DECIMAL，例如POWER(CAST(x AS DECIMAL(38,12)), CAST(0.5 AS DECIMAL(38,12)))
负数、边界值和浮点残差怎么兜底
精度问题常和域错误交织。比如上游算出 POWER(x, 2) - y，数学上应 ≥ 0，但浮点误差让它变成 -1e-15，直接喂给 SQRT 就崩。
- 永远别信“理论上不会负”，加
CASE WHEN expr 或更稳妥的 <code>SQRT(NULLIF(ABS(expr), 0)) - 对临界值先
ROUND(expr, 10)再判断，把-1e-15归零 - SQL Server 2022+ 可用
TRY_SQRT(expr)，出错不中断只返NULL；老版本只能靠CASE+ISNUMERIC（注意：ISNUMERIC不识别科学计数法，慎用） - 开立方等非常规根，别用
POWER(x, 1.0/3)，改用EXP(LOG(ABS(x))/3) * CASE WHEN x ，避开负底数+非整数指数陷阱
真正卡住精度的，从来不是函数本身，而是没意识到：SQL 的数值函数天生是浮点导向的，而你的业务要的是确定性。每一步 CAST、每一个 ROUND、每一次 CASE 兜底，都不是“多此一举”，是在把控制权从二进制表示手里抢回来。
