DECIMAL类型是MySQL数值精度的根基，因其按字符串存储十进制数，可精确运算；FLOAT/DOUBLE因二进制浮点导致舍入误差，金额等关键计算必须用DECIMAL(M,D)，并全程显式声明、CAST和控制小数位。
MySQL DECIMAL 类型才是数值精度的根基
MySQL 默认的 FLOAT 和 DOUBLE 是二进制浮点数，做加减乘除时会累积舍入误差——比如 0.1 + 0.2 可能存成 0.30000000000000004。这不是存储过程的问题，是底层类型选错了。
必须用 DECIMAL(M,D)：它按字符串方式存储十进制数，运算结果可精确到小数点后 D 位。
-
M是总位数（最大 65），D是小数位数（最大 30） - 比如金额计算常用
DECIMAL(15,2)，避免DECIMAL(10,2)在大额累加时溢出 - 存储过程中所有参与计算的变量、参数、临时表字段，只要涉及钱、比例、计费，一律声明为
DECIMAL，别图省事写DOUBLE
常见错误现象： 存储过程返回结果和 Excel 手动计算对不上，尤其在多轮累加/除法后偏差越来越大；SELECT 查出来看着是 100.00，但 IF (col = 100.00, ...) 却不进分支——因为实际存的是 99.99999999999999。
存储过程里避免隐式类型转换
MySQL 在表达式中混合 DECIMAL、INT、FLOAT 时会自动提升类型，但规则复杂且版本间有差异。最危险的是除法：DECIMAL / INT 看似安全，但若分母是计算结果（比如 ROUND() 返回的 DECIMAL），而你又没显式指定精度，MySQL 可能截断小数位。
- 所有中间计算结果，用
CAST(... AS DECIMAL(M,D))显式转类型，别依赖自动推导 - 除法务必写成
CAST(a AS DECIMAL(18,6)) / CAST(b AS DECIMAL(18,6))，而不是a / b -
ROUND()函数默认四舍五入到整数，要保留小数必须写全参数：ROUND(val, 4)，否则精度直接丢掉
性能影响： CAST 和显式 ROUND 带来微小开销，但远小于因精度错误导致的业务重算或人工核对成本。别为了省几个毫秒牺牲确定性。
函数调用链中的精度陷阱
存储过程常调用自定义函数做复利、税率分段、阶梯折扣等计算。问题在于：函数返回值类型若声明为 RETURNS DOUBLE 或没声明，默认就是 DOUBLE，上游再怎么用 DECIMAL 接也白搭。
- 自定义函数必须显式声明
RETURNS DECIMAL(M,D)，且M、D要覆盖所有可能输出范围 - 函数体内部所有变量、临时计算也得用
DECIMAL，不能因为“只是中间值”就用INT - 调用系统函数时注意：比如
POW(1.05, n)返回DOUBLE，必须立刻CAST(POW(...) AS DECIMAL(18,6))
容易踩的坑： 写完函数测试单条数据没问题，一跑批量就发现第 1000 行开始结果漂移——大概率是函数返回类型没锁死，或某处漏了 CAST。
调试时怎么确认真精度？
别信 SELECT 输出的格式化结果。MySQL 客户端默认只显示小数点后几位，掩盖了真实存储值。
- 查原始值用
SELECT LENGTH(CAST(col AS CHAR)), col+0.0000000000000001 FROM t—— 加一个极小量能暴露隐藏尾数 - 在存储过程中调试，用
SELECT CONCAT('DEBUG: ', col) INTO @debug_msg;再查@debug_msg，比直接SELECT col更可靠 - 导出到 CSV 时用
SELECT CAST(col AS CHAR) FROM t，避免客户端二次格式化
精度问题不是“运行慢”那种能一眼看出的 bug，它藏在数字末尾，只在对账、审计、跨系统同步时突然爆发。盯住每个类型声明、每次 CAST、每处除法的小数位控制，比优化循环逻辑重要得多。
