精度丢失本质是类型链断裂：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 是否显式声明、目标列定义是否足够宽——这三点漏一个，就掉坑里。
