DECIMAL在MySQL 8.0存储过程中可避免精度丢失，但必须声明完整（如DECIMAL(15,2)）、调用时传100.0而非100以防隐式转DOUBLE，并全程保持DECIMAL类型链路，否则将静默截断或漂移。
DECIMAL在MySQL 8.0存储过程中不会丢失精度——前提是声明完整、传参规范、运算链路不中断。 一旦漏写标度、传裸数字、混用FLOAT/DOUBLE，就会掉进静默截断或隐式转DOUBLE的坑里，结果看起来“差不多”，实则已错。
DECLARE变量时必须带(M,D)，不能只写DECIMAL
MySQL 8.0语法强制要求精度和标度，否则直接报ERROR 1064。这不是可选项，是硬性约束。
- ✅
DECLARE total_amount DECIMAL(15,2);—— 覆盖亿元级金额+分，最常用 - ✅
DECLARE exchange_rate DECIMAL(12,6);—— 汇率/利率场景，保留六位小数 - ❌
DECLARE total_amount DECIMAL;—— 语法错误 - ❌
DECLARE total_amount DECIMAL(15);—— 缺少标度，仍报错
标度D不能为负，且必须≤M；赋值超限时MySQL默认四舍五入（如DECIMAL(5,3)存123.4567→123.457），不报错，容易被忽略。
调用存储过程时传100.0而非100，避免隐式转DOUBLE
哪怕参数声明为DECIMAL(15,2)，只要调用时传100或0.08这种字面量，MySQL就按DOUBLE解析——中间一算，类型链就断了。
- ✅
CALL calc_tax(100.0, 0.08);—— 末尾加.0是最轻量的定点提示 - ✅
CALL calc_tax(CAST(100 AS DECIMAL(10,2)), CAST(0.08 AS DECIMAL(5,4)));—— 强制对齐，最稳妥 - ❌
CALL calc_tax(100, 0.08);——0.08被当DOUBLE，乘法结果大概率变成DOUBLE类型
执行前可查SELECT @@sql_mode;，确认不含ALLOW_INVALID_DATES等宽松模式，否则隐式转换更难察觉。
存储过程内部所有运算都要显式保DECIMAL链路
MySQL对DECIMAL运算结果有自动推导逻辑，但不总如预期：两个DECIMAL(10,2)相加得DECIMAL(11,2)，相乘得DECIMAL(20,4)。若你把结果塞进窄变量（如DECIMAL(10,2)），可能静默截断。
- ✅
SET @res = CAST(100 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2));—— 结果仍是DECIMAL - ❌
SET @res = 100 / 3;—— 返回DOUBLE，值约33.333333333333336 - ✅
SELECT ROUND(CAST(0.1 AS DECIMAL(10,2)) + CAST(0.2 AS DECIMAL(10,2)), 2);—— 从源头掐断误差
除法尤其危险；常量参与计算时，100.0比100更安全；SUM()、ROUND()对DECIMAL有效，但类型推导不总如预期。
真正容易被忽略的是类型链断裂后 MySQL 不报错也不警告
它只是默默给你一个“看起来对”的错值。比如你在某一步用了100 / 3，结果存进DECIMAL(10,2)变量，MySQL会先算出DOUBLE再四舍五入赋值——你看到33.33，但底层已不是定点运算，后续所有依赖它的计算都漂移了。
这种问题在复杂存储过程中极难定位，因为每一步单独看都没报错，只有最终业务结果对不上账时才暴露。所以从DECLARE到CALL再到每一条SET或SELECT ... INTO，都得盯住类型是否全程一致。
