必须全程使用decimal(18,6)显式控精度，因power等函数默认返回double导致二进制浮点误差，经多轮幂运算后指数级放大，使复利计算结果严重失真。

POWER函数默认返回DOUBLE，复利结果会漂移

直接写 POWER(1.05, 365) 算出来的不是 339291.61，而是类似 339300000.123456789 这种离谱值——这不是计算逻辑错，是 POWER 默认返回 DOUBLE 类型，而 DOUBLE 用二进制存小数，0.05 实际存的是 0.049999999999999996。幂运算放大误差后，第 365 次方时已完全失真。

金融计算中，哪怕 0.0001 元偏差也会导致账实不符，所以不能依赖函数默认类型。

所有变量和中间结果必须声明为DECIMAL(18,6)或更高

MySQL 存储过程中，别写 DECLARE @rate DECIMAL;——没括号就按 DECIMAL(10,0) 截断小数，0.05 直接变 0；也别用 FLOAT 或 DOUBLE 声明利率、本金、期数等任何参与计算的变量。

• DECLARE @principal DECIMAL(18,2);（本金保留两位小数）
• DECLARE @rate DECIMAL(18,8);（年化利率建议至少 8 位，避免 0.05000001 这类微小偏移）
• DECLARE @n INT;（期数用整数，避免 DECIMAL 反而引入隐式转换）
• 所有传入参数也要显式指定精度，例如 IN p_rate DECIMAL(18,8)

每次调用POWER/LOG/SQRT都必须立刻CAST

POWER()、LOG()、SQRT() 在 MySQL、SQL Server、Oracle 中一律返回浮点类型，不强制转换就等于把精度控制权交给了数据库引擎。

正确写法是：

CAST(POWER(1 + @rate, @n) AS DECIMAL(18,6))

而不是：

SkillHub

腾讯云专为中国用户推出的 Skill 极速安装工具

下载

POWER(1 + @rate, @n)

如果涉及多层嵌套，比如计算月复利： CAST(POWER(1 + @rate/12, @n*12) AS DECIMAL(18,6))，中间每一步都不能漏 CAST。

负底数非整数幂要绕开POWER，改用EXP+LOG组合

像 POWER(-1.05, 3.5) 这种写法，在 MySQL 里直接报错，SQL Server 返回 NULL，因为数学上结果是复数，而 SQL 不支持复数类型。

若业务真需要处理带符号的幂（如某些物理模型），得手动拆解：

CAST(EXP(@exponent * LOG(ABS(@base))) AS DECIMAL(18,6)) * CASE WHEN @base <p>注意：这里只对整数指数才翻负号，否则仍需拒绝输入——复利场景本就不该出现负底数非整数幂，这是模型设计问题，不是函数能补救的。</p><p>最常被忽略的一点：结果表字段定义必须匹配计算精度。就算你在存储过程里全用了 <code>DECIMAL(18,6)</code> 和 <code>CAST</code>，但结果表字段是 <code>DECIMAL(10,2)</code>，INSERT 时就会被无声截断。精度控制必须贯穿变量声明 → 函数调用 → 表结构 → INSERT 表达式四个环节，缺一不可。</p>