精度截断源于数据库列定义、驱动映射、计算表达式三者不匹配，须同步检查：确认DECIMAL的precision/scale足够、SQL中避免隐式类型转换、ORM/驱动显式指定numericScale。
直接结论：精度截断不是SQL语句写错了，而是数据库列定义、驱动映射、计算表达式三者不匹配导致的——必须同步检查这三层，缺一不可。
查清目标列的 precision 和 scale 是否足够
DECIMAL 字段的精度由 precision（总位数）和 scale（小数位数）共同决定。比如 DECIMAL(12,6) 最多存 6 位小数，但如果你 UPDATE 时传入 123.4567891（7 位小数），SQL Server 或 MySQL 都会在写入前强制截断或报错。
- SQL Server 查法：
sp_help 'your_table_name'或SELECT precision, scale FROM sys.columns WHERE object_id = OBJECT_ID('your_table') AND name = 'your_column' - MySQL 查法：
DESC your_table_name，看Type列是否为decimal(12,6)这类明确声明 - 别依赖 ORM 实体类里的注解——它不控制数据库行为，只反映开发假设
UPDATE 语句中避免隐式类型转换
一旦 SQL 里出现函数、运算或跨类型拼接，数据库可能自动降级精度。比如在 SQL Server 中写 UPDATE t SET amount = amount * 1.1，如果 amount 是 DECIMAL(10,2)，而 1.1 被推导为 NUMERIC(2,1)，乘法结果可能被截成 DECIMAL(12,3) 再往回塞，触发隐式舍入。
- 显式用
CONVERT或CAST控制中间类型：amount = CONVERT(DECIMAL(15,6), amount) * 1.1 - MySQL 中优先用
ROUND(expr, N)显式收口：amount = ROUND(amount * 1.1, 6) - 避免把
DECIMAL和FLOAT混用——FLOAT是二进制近似值，0.1 都存不准
ORM 或驱动层必须对齐 numericScale
MyBatis、Dapper 等框架本身不改精度，但若 JDBC/SqlClient 驱动没拿到足够信息，就会按默认规则处理。例如 MyBatis 默认不透传 numericScale，#{value} 可能被当成 DECIMAL(18,0) 传入，小数全丢。
- MyBatis 必须为每个 DECIMAL 参数显式声明：
#{item.price, jdbcType=DECIMAL, numericScale=6} - SQL Server JDBC 连接串加
sendDecimalAsBigDecimal=true，否则旧驱动可能把 DECIMAL 当 double 处理 - Dapper 推荐用
Microsoft.Data.SqlClient，并确认查询返回值GetType()确实是System.Decimal，不是Double
批量更新时 MERGE INTO 的精度陷阱
MERGE INTO 在 SQL Server 中常用于 upsert，但它对源数据精度更敏感：目标列是 DECIMAL(18,2)，但你从 VALUES 子句传入 123.45678，SQL Server 不会警告，而是静默截成 123.45 再比对 ON 条件——可能导致本该 UPDATE 的行被当作 NOT MATCHED 插入。
- VALUES 子句里每个 DECIMAL 值都需绑定精度，不能只靠列定义推断
- 避免在
#{item.a} + #{item.b}这类表达式里做运算——MyBatis 无法准确推导类型，优先拆成预计算字段传入 - 用 SQL Server Profiler 抓真实参数值，确认传入的是
@p0 = 123.45678还是已被驱动缩成123.45
真正容易被忽略的点是：错误日志里通常不告诉你哪一层丢了精度——可能是表结构不够、可能是驱动配置漏了、也可能是 SQL 里一个没注意的 CONVERT 把 scale 写成了 2。排查时得从数据库列定义开始，一层层往上对，而不是盯着代码猜。
