“String or binary data would be truncated”错误发生在INSERT/UPDATE时实际值长度超过目标字段定义长度，常见于临时表字段过窄、动态SQL变量截断、STRING_SPLIT未清洗空值等场景。
“String or binary data would be truncated”到底卡在哪儿？
这个错误不是警告，是硬性终止——SQL Server 拒绝执行，且不告诉你具体哪一列超长。它只发生在 INSERT 或 UPDATE 语句写入目标字段时，实际值长度 > 字段定义长度。常见于：临时表字段比源表窄、存储过程中拼接字符串后直接赋值给过短变量、或客户端传入参数未做长度校验就进存储过程。
别急着改字段长度。先确认是不是真由字段长度引起：用 SELECT LEN(@param) 和 DATALENGTH(@param) 对比参数实际字节数；再查目标列定义：SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'xxx' AND COLUMN_NAME = 'yyy'。
临时表字段太窄是最隐蔽的坑
很多存储过程会建临时表中转数据，比如 CREATE TABLE #tmp (Name NVARCHAR(50))，但源表 Name 是 NVARCHAR(200)。一旦插入超长值，立刻报截断错误，且堆栈里不显示临时表名。
- 检查所有
CREATE TABLE #xxx或SELECT INTO #xxx语句，逐个比对字段长度与源表/输入参数 - 避免用
SELECT col1, col2 INTO #tmp FROM ...自动生成结构——它按首行数据推断长度，可能严重缩水 - 显式声明临时表，字段类型和长度严格对标源表，尤其是
NVARCHAR和VARCHAR别混用
EXEC 执行动态 SQL 时字符串被静默截断
EXEC @sql 不报错，但若 @sql 是 VARCHAR(4000)，而拼出的语句实际 4050 字节，就会丢掉尾巴，导致语法错误或逻辑错乱。你看到的 “无法识别的字符” 或 “附近语法不正确”，往往就是这原因。
解决方法很简单但容易忽略：
- 把变量声明为
NVARCHAR(MAX)，不是VARCHAR(8000)或NVARCHAR(4000) - 拼接前用
LEN(@sql)+PRINT @sql看是否完整（PRINT最多输出 4000 字符，所以必须配合LEN判断） - 执行时写成
EXEC sp_executesql @sql，比EXEC @sql更稳，且支持参数化防注入
STRING_SPLIT 返回空字符串或空格引发隐性截断
当传入 @csv = '1,,2, 3 ' 给 STRING_SPLIT(@csv, ',')，它会返回 '1'、''、'2'、' 3 ' 四行。如果后续用 TRY_CAST(s.value AS INT) 还好，但若直接插入 NVARCHAR(10) 字段，那个空字符串 '' 或带空格的 ' 3 ' 就可能因 trim 缺失或长度误判触发截断。
务必在 JOIN 前清洗：
- 加
WHERE NULLIF(LTRIM(RTRIM(s.value)), '') IS NOT NULL过滤空值和纯空格 - 插入前用
LEFT(s.value, 10)或CONVERT(NVARCHAR(10), s.value)显式截断，别依赖目标字段自动裁剪 - 若拆分结果要进临时表，该表对应字段长度必须 ≥ 源字段，且明确设为
NVARCHAR（别用VARCHAR存 Unicode 内容）
真正麻烦的从来不是“哪里错了”，而是错误发生时你根本不知道它正在哪个临时表、哪次 EXEC、哪一行 STRING_SPLIT 里悄悄截掉最后两个字节。盯住变量长度声明、临时表结构、以及所有隐式转换发生的边界点，比盲目加长字段更有效。
