本质是数据超出字段定义精度或长度，需逐层排查：sql server列定义（precision/scale、max_length）、jdbc驱动参数（如senddecimalasbigdecimal）、orm显式声明（numericscale）、隐式类型转换及外部工具（如excel类型猜测）导致的中间截断。
SQL Server 插入时出现精度截断（如 DECIMAL 小数位丢失、字符串被砍掉），本质是数据“装不进”字段定义——要么字段精度/长度太小，要么 JDBC 或驱动在类型传递时做了隐式降级。
查清到底是哪一层在截断
错误信息本身不指明位置，得逐层确认：
- 先看 SQL Server 报错是否带具体字段名；不带就用
sp_help 表名查目标列的precision和scale（对 DECIMAL）或max_length（对字符串） - 对比你插入的实际值：比如 Java 传
new BigDecimal("123.45678")，而目标列是DECIMAL(10,2)，小数位直接被 SQL Server 截成123.45 - 如果是 MyBatis + MERGE INTO 场景，
#{item.value, jdbcType=DECIMAL, numericScale=5}中漏写numericScale，JDBC 驱动可能按默认规则舍入 - 用 SQL Server Profiler 捕获真实执行语句，看传入参数是否已失真（例如日志里显示
@p0 = 123.45而不是123.45678）
MyBatis 中 DECIMAL 精度丢失的硬解法
MyBatis 默认不透传精度，必须显式声明：
- 在
<foreach></foreach>内部每个 DECIMAL 参数都加jdbcType=DECIMAL和numericScale=N，N 必须与数据库列定义一致 - 避免在
VALUES子句里拼复杂表达式，比如#{item.a} + #{item.b}—— 这会让 MyBatis 无法准确推断类型，优先改用临时表或表变量批量传入 - 连接串加上
sendDecimalAsBigDecimal=true，否则某些旧版 SQL Server JDBC 驱动会把 DECIMAL 当 double 处理，造成二进制精度污染
字符串截断：别只盯着 varchar(n) 的 n
常见误区是以为调大 varchar 就万事大吉，但还有几个隐蔽点：
-
nvarchar(n)的n是字符数，不是字节数；插入含 emoji 或生僻汉字时，单个字符仍占 2 字节，但长度判断按字符计 —— 所以nvarchar(10)能存 10 个中文，但不能存 11 个 - 隐式转换陷阱：比如往
varchar(5)插入整数123456，SQL Server 会先转成字符串'123456'（6 字符），立刻报错，而非按数值截断 - Excel 导入时，Jet/ACE 引擎默认只读前 8 行猜字段类型，若这 8 行最长字符串是 50 字符，它就建
nvarchar(50)，后面遇到 100 字符就崩 —— 改注册表TypeGuessRows=0强制全扫
ALTER COLUMN 不总是安全的
直接 ALTER TABLE ... ALTER COLUMN 扩容看似简单，但要注意：
- 如果字段有索引、约束、外键或被视图引用，可能失败，需先删后建
- 修改
DECIMAL(p,s)时，p增大没问题，但s（小数位）增大可能导致现有数据隐式补零（如12.3变成12.300），而s缩小则直接报错 - 生产环境改结构前，务必在相同版本 SQL Server 上用真实数据量压测，
ALTER COLUMN对大表可能是锁表操作
真正麻烦的从来不是“怎么扩字段”，而是“谁在中间悄悄改了精度”——JDBC 驱动、ORM 框架、ETL 工具、甚至 Excel 导入向导，都可能成为精度丢失的黑盒。定位时优先抓 SQL Server 实际收到的参数值，而不是相信代码里传进去的是什么。
