根本不用处理浮点数精度丢失，应全程使用带精度和标度的decimal类型，禁用float/double；声明变量、传参、运算均需显式指定(m,d)，避免隐式转换导致精度丢失。
根本不用“处理”浮点数精度丢失——直接禁用 FLOAT 和 DOUBLE，全程用 DECIMAL 定义变量、参数、字段，并显式控制类型链路。所谓“优雅”，就是不跟 IEEE 754 较劲，换赛道。
存储过程里声明 DECIMAL 变量必须带 (M,D)
MySQL 不接受裸 DECIMAL，漏写精度和标度会直接报 ERROR 1064。这不是可选项，是语法铁律。
-
DECLARE total_amount DECIMAL(15,2);✅ 覆盖亿元级金额 + 分，安全常用 -
DECLARE exchange_rate DECIMAL(12,6);✅ 汇率/利率场景，六位小数够用 -
DECLARE x DECIMAL;❌ 语法错误 -
DECLARE y DECIMAL(10);❌ 缺少标度，仍报错
标度 D 不能为负，且必须 ≤ M；赋值超限时 MySQL 默认四舍五入截断（如 DECIMAL(5,3) 存 123.4567 → 123.457），不报错也不警告，极易被忽略。
调用存储过程时传 100.0 而不是 100
哪怕参数声明为 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 链路
除法尤其危险：100 / 3 直接返回 DOUBLE；而 CAST(100 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2)) 才保持 DECIMAL 类型输出。
-
SUM()、ROUND()、TRUNCATE()对DECIMAL有效，但类型推导不总如预期：两个DECIMAL(10,2)相乘，结果是DECIMAL(20,4)；相加是DECIMAL(11,2) - 若把
DECIMAL(20,4)结果赋给DECIMAL(10,2)变量，超长部分静默四舍五入，不报错 -
SELECT ROUND(0.1 + 0.2, 2);是显示层补救，底层仍是浮点误差再修；CAST(0.1 AS DECIMAL(10,2)) + CAST(0.2 AS DECIMAL(10,2));才是从源头掐断
真正容易被忽略的是：类型链一旦断裂（比如某个中间值被当成 DOUBLE），后续所有计算都跟着漂移，而 MySQL 不报错、不警告——它只是默默给你一个“看起来对”的错值。
