必须全程使用decimal显式控精度，因float/double的二进制浮点误差从首行即开始漂移，经power等函数多轮运算后指数级放大，导致复利等关键计算结果失真；所有变量、函数返回值、中间计算及除法操作均需声明decimal(18,6)并强制cast。
别用 FLOAT 或 DOUBLE 做数学运算——误差从第一行就开始漂移，到第1000行时结果已不可信。必须全程用 DECIMAL 显式控精度，函数返回值、中间变量、参数声明、除法操作，一个都不能漏。
为什么 POWER(1.05, 365) 算出来是 339300000.123456789 而不是 339291.61？
因为 POWER() 默认返回 DOUBLE，而 DOUBLE 是二进制浮点数，0.05 实际存的是近似值。多轮幂运算后误差指数放大，尤其在复利、折旧、物理建模这类场景里，偏差会直接导致账目对不上。
- 所有参与计算的变量必须声明为
DECIMAL(18,6)或更高（如利率用DECIMAL(18,8)），别写DECIMAL不带括号，MySQL 默认按DECIMAL(10,0)截断小数 -
POWER()、LOG()、SQRT()等函数返回DOUBLE，必须立刻包裹：CAST(POWER(1.05, @n) AS DECIMAL(18,6)) - 负底数非整数幂（如
POWER(-2.5, 1.3)）在 MySQL 报错、SQL Server 返回NULL；改用EXP(1.3 * LOG(2.5)) * CASE WHEN -2.5
WHILE 循环里做牛顿法或梯度下降，为什么总卡死或发散？
不是循环语法错了，而是数值稳定性被忽略了。MySQL 的 LOG() 和 EXP() 在极小/极大值附近精度骤降，收敛判定若只看绝对误差，很容易陷入无限循环。
- 收敛条件别用
ABS(f(x)) ，改用相对误差：<code>ABS((x_new - x_old) / x_new) - 必须设最大迭代次数兜底：
SET @iter = 0; WHILE @iter - 导数尽量解析化，比如求
LN(x) - k = 0的根，导数就是1/x，别用数值微分（如(f(x+h)-f(x))/h），那会引入第二层误差
自定义函数返回值类型没锁死，为什么单条测试正常、批量就偏移？
函数体内部用 INT 或 DOUBLE 临时算一下，看起来没问题；但函数签名若写成 RETURNS DOUBLE，上游再怎么 CAST 也救不回精度——类型在函数出口那一刻就定死了。
- 函数定义必须明确写：
RETURNS DECIMAL(18,6) - 函数体内所有中间变量也要声明为
DECIMAL(18,6)，不能因“只是临时”就省略 - 除法必须显式控制：
CAST(@a AS DECIMAL(18,6)) / CAST(@b AS DECIMAL(18,6))，别依赖自动类型提升 -
ROUND()必须带小数位参数：ROUND(val, 6)，否则默认取整，精度直接丢掉
真正容易被忽略的，不是某一行 CAST 漏了，而是整个链条——从参数进来、每一步运算、每个函数调用、到最终插入表字段——都得主动声明精度。靠数据库“自动处理”，等于把钱的精度交给 IEEE 754 标准随机决定。
