聚合函数返回类型继承输入列类型，DECIMAL列聚合后仍为DECIMAL，但混入FLOAT或整数字面量会触发DOUBLE隐式转换导致浮点误差；必须对聚合结果CAST而非原始列，并确保全程定点运算。
聚合结果类型由输入列决定，不是函数本身
SQL 中 SUM()、AVG() 等聚合函数的返回类型，**完全继承自输入列的数据类型**。比如 amount DECIMAL(10,2) 聚合后仍是 DECIMAL；但若列是 FLOAT，或表达式里混入了整数、浮点字面量（如 / 100），整个计算链就会被隐式拉进 DOUBLE 域，立刻引入二进制浮点误差。
常见错误现象：
-
SUM(amount) / 100→100是整型，MySQL 默认转成DOUBLE计算，结果变成46.54999999999999 -
SUM(amount) * 0.01→0.01是浮点字面量，强制升为DOUBLE -
COALESCE(amount, 0)→ 若amount是FLOAT，COALESCE返回类型仍是FLOAT，聚合无效
CAST 必须作用于聚合结果，且参数要匹配业务精度
CAST 不是“修复已失真的值”，而是确保计算全程在定点数域内执行。关键在于：必须对聚合结果本身做 CAST，而不是只 cast 原始列。
正确写法示例：
-
CAST(SUM(COALESCE(amount, 0)) AS DECIMAL(18,4)) / 100.0（末尾加.0显式声明为定点常量） -
CONVERT(AVG(price), DECIMAL(15,2))（MySQL 中等价，但可读性略弱）
精度参数不能拍脑袋定：DECIMAL(18,4) 表示总长 18 位、小数占 4 位。若原始字段是 DECIMAL(10,2) 且要支持 1000 行求和，整数位需 ≥ 10 + log₁₀(1000) ≈ 13，即 DECIMAL(15,2) 更稳妥。
除法、常量、混合类型会悄悄触发隐式转换
这些写法看似无害，实则绕过所有精度控制：
-
SUM(amount) / 100→ 整数常量触发DOUBLE转换 -
ROUND(0.0068, 4) * 100→ 输入是DOUBLE字面量，ROUND输出仍是DOUBLE -
SELECT CONCAT(ROUND(x, 2) * 100, '%')→ROUND结果先失真，再转字符串，误差已固化
真正安全的做法是：从源头用 DECIMAL 定义字段，所有中间运算都保持定点语义，避免任何未声明类型的字面量参与算术。
BI 工具和 JDBC 接收端不处理，SQL 层 CAST 就白做
即使 SQL 输出了 DECIMAL(18,4)，下游不配合照样丢精度：
- Power BI 自动识别为 “Decimal Number” 后仍可能按
double解析，必须手动设置该字段为「固定小数位数」并指定精度 - Java JDBC 默认把
DECIMAL映射为Double，必须用ResultSet.getBigDecimal()，而非getDouble() - 验证是否真生效：在数据库客户端执行 SQL，复制结果值粘贴到文本编辑器——如果看到
46.5500而不是46.54999999999999，说明CAST生效了
实际精度问题往往卡在“以为 CAST 过了就安全”，却没检查上游字段定义、中间运算常量、下游接收方式这三个环节。
