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