精度丢失，究其本质，乃是类型链的断裂所致。

比如，BigDecimal未传递scale参数，DECIMAL列定义过窄，以及SQL Server的money类型未被MyBatis默认识别，这三种情况导致了80%以上的问题。

就像BigDecimal(35.35, scale=2)最终存储为35，这是因为JDBC驱动未能获取到小数位信息。

直接说结论：精度丢失不是“数据错了”，而是类型链在某处断裂。

• BigDecimal没传scale
• DECIMAL列定义窄于实际值
• SQL Server 的 money 类型不认 MyBatis 默认映射

这三者占了八成以上问题。

MyBatis 插入 BigDecimal 到 SQL Server 时小数被截成整数

现象是 BigDecimal(35.35, scale=2) 最终存成 35。

这不是代码算错，而是 JDBC 驱动根本没拿到小数位信息。

• SQL Server 的 money 类型本质是 DECIMAL(19,4)，但它是专有类型，MyBatis 的默认 BigDecimalTypeHandler 不识别它，也不传 scale
• 低版本 mssql-jdbc 驱动对 money 列调用 setBigDecimal() 时直接丢弃 scale，高版本需显式加连接参数：calcBigDecimalPrecision=true
• 更稳妥的做法是在 MyBatis XML 中强制指定类型和精度：#{item.amount, jdbcType=DECIMAL, numericScale=2}
• 如果字段是 money 类型又不能改表结构，可临时 cast：cast(#{item.amount} as decimal(19,4))

MySQL 函数内浮点运算结果不准

函数里写 DECLARE total DECIMAL; 或 DECLARE total DECIMAL(10);，都会报错或静默失效。

MySQL 要求必须带标度，也就是必须写出小数位数。

• 所有变量、参数、返回值声明都必须写全：DECIMAL(15,2)，漏掉 (M,D) 就不合法
• 调用时传 100 或 0.08 这种字面量，MySQL 默认当 DOUBLE 解析，中间一算就漂移；得传 100.0 或 CAST(0.08 AS DECIMAL(5,4))
• SUM() 或除法结果类型会自动推导，比如两个 DECIMAL(10,2) 相除，结果可能是 DECIMAL(20,4)，若你塞进 DECIMAL(10,2) 变量，会静默四舍五入截断

Bulk insert 时批量插入 DECIMAL 字段精度统一丢失

这不是每条都错，而是整个批次按“最窄精度”处理。

比如列表里有个值是 123.4567，目标列是 DECIMAL(10,2)，那所有值都会被截到两位小数，哪怕其他值原本只有一位。

• 根源在 SQL Server 的类型推导机制：MERGE INTO 或批量 VALUES 子句中，驱动未显式传递精度，SQL Server 按目标列定义反向约束源数据
• MyBatis XML 中每个数值参数必须单独加 jdbcType 和 numericScale，不能只靠列定义
• 更粗暴但有效的办法：在 SQL 里 cast，例如 cast(#{item.value} as decimal(22,6))，强制覆盖类型推导
• 数据库层同步检查：用 SELECT COLUMN_NAME, NUMERIC_PRECISION, NUMERIC_SCALE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'xxx' 确认列定义是否真匹配业务需求

排查重点

真正容易被忽视的是：精度丢失常常不会报错，而是悄悄地改变数值。

查看日志会发现SQL执行没有问题，debug时Java对象也没问题，问题就卡在JDBC TypeHandler → 驱动 → SQL Server类型协商这个黑盒子里。

一定要紧盯以下三点：

• scale 是否被传递
• numericScale 是否显式声明
• 目标列定义是否足够宽

这三点只要漏了一个，就会掉进坑里。

《夸克》非常好用的免费AI浏览器

下载APP查看