向表变量插入值时为何添加尾随空格？TRIM()为何影响所有行？

嘿，这两个现象其实都和SQL Server的字符串类型推断以及CHAR/VARCHAR的行为差异直接相关，我来给你逐一拆解：

现象1：长度为2的分隔符行自动添加了尾随空格 #

你的@delimiters表中delim字段定义为VARCHAR(10)，但问题出在INSERT语句里的字符串表达式类型：

• CHAR(n)函数返回的是固定长度CHAR类型，而非可变长度VARCHAR。比如CHAR(10)+CHAR(13)是两个CHAR(1)拼接，结果是CHAR(2)；而第一行的CHAR(10)+CHAR(32)+CHAR(13)是三个CHAR(1)拼接，结果是CHAR(3)。
• SQL Server在处理VALUES子句时，会对同一列的所有表达式做统一类型推断：它会选择最长的字符类型长度作为目标类型。这里最长的是CHAR(3)，所以第二、三行的CHAR(2)会被自动填充空格到长度3（CHAR类型的特性：固定长度，不足补空格），然后插入到VARCHAR(10)字段中，最终就带上了尾随空格。

这就导致REPLACE匹配失败：原字符串中的分隔符是2个字符，但表中的delim是3个字符（加了空格），自然无法匹配。

你可以运行这条查询验证：

SELECT Id, delim, LEN(delim) AS [显示长度(忽略空格)], DATALENGTH(delim) AS [实际字节长度] 
FROM @delimiters

第一个INSERT后，Id2和3的DATALENGTH会是3，而LEN是2（LEN函数会忽略尾随空格）。

现象2：对任意一行的CHAR()用TRIM()，所有行的尾随空格都消失了 #

TRIM()函数有个关键特性：它的返回值是VARCHAR类型（即使输入是CHAR）。当你在第一行的表达式中使用TRIM(CHAR(10))时：

• 这个表达式的结果是VARCHAR(1)，后续和CHAR(32)、CHAR(13)拼接时，根据SQL Server的数据类型优先级，VARCHAR的优先级高于CHAR，所以整个拼接结果会被转换为VARCHAR(3)。
• 此时VALUES子句中的其他行（比如CHAR(10)+CHAR(13)），原本是CHAR(2)，但因为列表中已经有VARCHAR类型的表达式，SQL Server会把所有行的delim表达式隐式转换为VARCHAR类型。而VARCHAR是可变长度，不会自动填充空格，所以第二、三行的分隔符就保持了原本的2个字符长度，没有尾随空格，REPLACE就能正确匹配了。

额外建议 #

如果想避免这类问题，建议在拼接分隔符时显式转换为VARCHAR类型，比如：

INSERT INTO @delimiters
VALUES
(1, CAST(CHAR(10) AS VARCHAR(1)) + CAST(CHAR(32) AS VARCHAR(1)) + CAST(CHAR(13) AS VARCHAR(1)), '$'),
(2, CAST(CHAR(10) AS VARCHAR(1)) + CAST(CHAR(13) AS VARCHAR(1)), '#'),
(3, CAST(CHAR(13) AS VARCHAR(1)) + CAST(CHAR(10) AS VARCHAR(1)), '@')

这样所有表达式都是VARCHAR类型，不会触发CHAR的自动填充行为。

内容的提问来源于stack exchange，提问作者Dontjoshme