SQL数学函数无法解决浮点精度问题，根本原因是FLOAT/DOUBLE类型本身无法精确表示十进制数；真正有效的是全程使用DECIMAL类型并配合CAST显式转换，从源头切断浮点链路。
没有 SQL 数学函数能“解决”浮点数精度丢失问题——精度丢失根源在 FLOAT 和 DOUBLE 类型本身，函数只是在已有类型上运算。真正起效的是类型选择与显式转换，不是函数选得对不对。
为什么 ROUND、TRUNCATE、CEILING 这些函数救不了精度
它们只作用于输入值的“表现形式”，不改变底层数据类型和计算路径。如果输入已经是 DOUBLE，比如 0.1 + 0.2 算出来是 0.30000000000000004，那 ROUND(0.1 + 0.2, 2) 实际是在对这个错误值四舍五入，结果可能是 0.3（看起来对），但中间链路已漂移，后续再参与除法或比较就暴露问题。
常见错误现象：
-
SELECT ROUND(SUM(amount), 2) FROM sales;返回199.99，但导出到 Excel 后对不上总和 -
WHERE ROUND(price, 2) = 19.99查不到数据，因为原始price是DOUBLE，存的是19.989999999999998
真正该用的不是“函数”，而是 DECIMAL + CAST 组合
所有精度敏感场景（金额、汇率、计费）必须切断浮点链路，从源头用定点十进制。关键不是调哪个函数，而是让每个参与计算的值都落在 DECIMAL(M,D) 轨道上。
- 建表时字段定义必须写满：例如
amount DECIMAL(15,2)，不能只写DECIMAL或DECIMAL(15)（MySQL 会报错） - 查询中临时转类型：用
CAST(price AS DECIMAL(10,2))，不是ROUND(price, 2) - 存储过程里声明变量：必须带标度，如
DECLARE total DECIMAL(19,4);，漏掉(19,4)就失效 - 传参时防隐式转换：调用
CALC_TAX(100.0, 0.08)比CALC_TAX(100, 0.08)安全，因为100.0更可能被识别为定点常量
哪些函数在 DECIMAL 链路上才真正可靠
一旦整个计算链锁定为 DECIMAL，这些函数行为可预测、无漂移：
-
SUM()：两个DECIMAL(10,2)相加，结果是DECIMAL(11,2)；相乘是DECIMAL(20,4)—— MySQL 有明确定义，不会突变成DOUBLE -
ROUND()：当输入是DECIMAL(10,3)，ROUND(x, 2)输出仍是DECIMAL(10,3)（第三位补零），不是自动缩容，要截断需再CAST(... AS DECIMAL(10,2)) -
TRUNCATE()（MySQL 特有）：比ROUND()更适合分账类逻辑，不四舍五入，避免人为进位偏差 -
CONVERT()/CAST()：不是数学函数，却是精度控制的核心操作符；没它，其他函数全是空中楼阁
最容易被忽略的点：类型链只要断一次（比如某个中间值被当成 DOUBLE），后续所有 ROUND、SUM、AVG 都跟着失准，而 MySQL 不报错、不警告，只默默给你一个“看起来对”的错值。
