MySQL存储过程复杂数学运算必须用DECIMAL(M,D)全程显式声明与CAST，因FLOAT/DOUBLE二进制浮点导致0.1+0.2≠0.3；POWER、SQRT等函数默认返回DOUBLE必丢精度，须绕开或立即CAST；ROUND仅修显示不改底层误差。
直接说结论：MySQL 存储过程里做复杂数学运算，必须用 DECIMAL 类型打底，所有中间计算显式 CAST，关键函数（如 POWER、SQRT）默认丢精度，得绕开或补救。不是函数不够用，是类型和隐式转换在背后悄悄改结果。
为什么 ROUND(x,2) 挡不住 0.1 + 0.2 ≠ 0.3？
因为底层类型错了。FLOAT 和 DOUBLE 是二进制浮点，加减乘除会累积误差——ROUND 只是“四舍五入显示”，不改变存储值。比如：
SELECT 0.1 + 0.2 = 0.3; -- 返回 0 SELECT ROUND(0.1 + 0.2, 1) = 0.3; -- 看似对，但实际比较的是 ROUND(0.30000000000000004, 1) → 0.3，掩盖了问题
真正要做的，是从源头锁死类型：
- 输入参数声明为
IN p_amount DECIMAL(15,4)，别用DOUBLE - 中间变量全用
DECIMAL(18,6)，哪怕只是临时存个系数 - 连
SELECT ... INTO @var的目标变量，也得先DECLARE @var DECIMAL(18,6)
POWER、SQRT 这类函数为什么一用就变 DOUBLE？
MySQL 文档明确写：这些函数返回 DOUBLE，无论输入是不是 DECIMAL。例如：
SELECT POWER(DECIMAL '1.05', 12); -- 结果是 DOUBLE，可能存成 1.7958563260221303
这会导致后续除法、比较全乱套。应对方式只有两个：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 能不用就不用：比如
POWER(x, 2)改成x * x；POWER(x, 0.5)改成应用层计算 - 非用不可时立刻
CAST：写成CAST(POWER(1.05, 12) AS DECIMAL(18,6))，且确保幂次是整数（小数幂必然转DOUBLE）
注意：ROUND(POWER(...), 4) 不行——ROUND 输入已经是 DOUBLE，误差已产生。
聚合与除法场景下，AVG() 和 / 怎么不丢精度？
AVG() 对 DECIMAL 字段默认保持精度，但结果的小数位数由 MySQL 自动推导（通常是 D+4），不可控。除法更危险：DECIMAL / INT 看似安全，但若分母是 ROUND(...) 结果，而你没指定返回精度，MySQL 可能按 DECIMAL(10,0) 处理，小数直接归零。
- 写除法必须两边都
CAST：CAST(a AS DECIMAL(18,6)) / CAST(b AS DECIMAL(18,6)) -
AVG()后强制转：CAST(AVG(price) AS DECIMAL(15,4)) -
SUM()安全，但要注意字段定义的M是否够大——DECIMAL(10,2)存不了 1 亿订单的总金额
真正容易被忽略的点是：函数返回值类型声明比函数体逻辑还重要。自定义函数如果写 RETURNS DOUBLE，上游再怎么 CAST 也没用；而 RETURNS DECIMAL(15,4) 才是精度链的最后一道锁。别让一个没声明的 RETURNS，毁掉整条计算流水线。
