聚合结果类型由输入字段决定，SUM/AVG返回类型严格继承输入列类型；隐式转换（如除法、浮点常量）会降级为FLOAT/DOUBLE引发精度误差；CAST必须作用于聚合结果或原始列再聚合，且需匹配业务精度需求，并确保BI/JDBC正确处理DECIMAL。
聚合结果类型由输入字段决定，不是函数本身
MySQL、PostgreSQL 等数据库中，SUM()、AVG() 的返回类型**严格继承自输入列的数据类型**。比如 amount DECIMAL(10,2) 聚合后仍是 DECIMAL；但若列是 FLOAT 或参与了隐式转换（如 amount / 100 中 100 是整型），结果可能降级为 FLOAT 或 DOUBLE，立刻引入二进制浮点误差。
CAST 和 CONVERT 不是“修复”，而是显式控制类型路径
用 CAST(SUM(col) AS DECIMAL(18,4)) 并非把已失真的浮点数“变精确”，而是确保整个计算链路始终在定点数域内执行。关键点：
-
CAST必须作用于聚合结果本身，而不是原始列（CAST(col AS DECIMAL)再SUM才真正起效） -
CONVERT在 MySQL 中语法为CONVERT(SUM(col), DECIMAL(18,4))，语义等价，但可读性略弱于CAST - 精度参数不能拍脑袋定：
DECIMAL(18,4)表示最多 18 位总长、小数占 4 位，若原始字段是DECIMAL(10,2)且要支持 1000 行求和，小数位至少保留 2 位，整数位需 ≥ 10 + log₁₀(1000) ≈ 13，即DECIMAL(15,2)更稳妥
常见踩坑写法：除法、常量、混合类型直接触发隐式转换
这些写法看似无害，实则悄悄把 DECIMAL 拉进浮点陷阱：
-
SUM(amount) / 100→ 100 是整型，MySQL 默认转成DOUBLE计算，结果失真 -
SUM(amount) * 0.01→0.01是浮点字面量，强制整条表达式升为DOUBLE -
SUM(COALESCE(amount, 0))→ 若amount是FLOAT，COALESCE返回类型仍是FLOAT，聚合无效 - 正确写法：
CAST(SUM(COALESCE(amount, 0)) AS DECIMAL(18,4)) / 100.0（末尾加.0显式声明为定点常量）
BI 工具或应用层再处理，等于前功尽弃
即使 SQL 层用 CAST 输出了 DECIMAL(18,4)，Power BI 自动识别为 “Decimal Number” 后仍可能按 double 解析；Java JDBC 默认把 DECIMAL 映射为 Double。所以：
- BI 工具里必须手动设置该字段为「固定小数位数」并指定精度，不能依赖自动推断
- JDBC 查询时用
ResultSet.getBigDecimal()，而非getDouble() - 验证是否真生效：在数据库客户端执行 SQL，复制结果值粘贴到文本编辑器——如果看到
46.5500而不是46.54999999999999，说明CAST生效了
实际精度问题往往卡在“以为 CAST 过了就安全”，却没检查上游字段定义、中间运算常量、下游接收方式这三个环节。少一个，前面的 CAST 就只是自我安慰。
