DECIMAL是MySQL存储过程中避免浮点精度丢失的根本方案，需显式声明精度和标度（如DECIMAL(15,2)），传参时用CAST或带小数点常量防止隐式转DOUBLE，并全程统一类型链以保障定点运算准确性。
DECIMAL 是 MySQL 存储过程中处理浮点数精度丢失最直接有效的手段——它不是“提高浮点精度”，而是彻底绕开 IEEE 754 二进制浮点体系，改用定点十进制运算。只要声明得当、参与计算的值类型一致，存储过程内不会出现 0.1 + 0.2 = 0.30000000000000004 这类问题。
存储过程里定义 DECIMAL 变量要带精度和标度
MySQL 不允许只写DECIMAL，必须指定 M（总位数）和 D（小数位数），否则会报错 ERROR 1064。
例如在 CREATE PROCEDURE 中：
✅ 正确：DECLARE total_amount DECIMAL(15,2);
❌ 错误：DECLARE total_amount DECIMAL; 或 DECLARE total_amount DECIMAL(15);（缺少标度）
-
DECIMAL(15,2)表示最多存 13 位整数 + 2 位小数，范围是-9999999999999.99到9999999999999.99 - 如果业务涉及汇率或高精度计费，可选
DECIMAL(12,6)；纯金额场景常用DECIMAL(15,2) - 标度
D不能为负，且必须 ≤M；设成DECIMAL(5,3)却赋值123.4567，会静默截断为123.457（四舍五入），不是报错
传参和调用时别让 DECIMAL 被隐式转成 DOUBLE
存储过程参数若声明为DECIMAL，但调用时传入的是裸数字（如 10.5），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，尤其除法：CAST(100 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2))结果仍是DECIMAL；而100 / 3直接返回DOUBLE
函数调用和计算链中 DECIMAL 的精度推导规则
MySQL 8.0+ 对DECIMAL 运算结果的精度有自动推导逻辑，但不总是符合直觉。比如两个 DECIMAL(10,2) 相加，结果类型是 DECIMAL(11,2)；相乘则变成 DECIMAL(20,4)。超出列定义宽度时，INSERT 会报错，但存储过程内变量赋值可能截断。
常见陷阱：SELECT SUM(price) FROM orders; 返回类型取决于 price 列定义；但如果在存储过程中用 SELECT SUM(price) INTO @total，而 @total 声明为 DECIMAL(10,2)，但实际和超过 10 位，就会被截断——不会报错，但数据已损。
- 安全做法：声明接收变量时留足余量，比如预期最大和是亿元级，用
DECIMAL(18,2)而非DECIMAL(10,2) -
ROUND()和TRUNCATE()对DECIMAL安全有效，但ROUND(x, 2)返回类型仍是DECIMAL，精度由输入决定；不要依赖它“修复”上游已失准的DOUBLE - 避免在存储过程中混用
FLOAT/DOUBLE参数和DECIMAL变量做计算，类型混合极易触发隐式升格到DOUBLE
DECIMAL 的精度保障就可能在无声中失效**。它不像建表那样一劳永逸，而是一条需要全程盯紧的类型链。 
