SQL Server里字符串操作那些坑和细节你得留神点，不然容易出错

在日常使用SQL Server进行数据查询和处理时，字符串操作是绕不开的一环，但正是这些看似简单的操作，里面藏着不少容易让人栽跟头的细节，如果不留神，轻则查询结果错误，重则可能导致数据更新出错或应用程序逻辑异常,下面就来详细说说这些需要你特别留神的地方。

最经典也最容易出错的莫过于字符串末尾的空格问题了，根据关系数据库理论的奠基人埃德加·F·科德（Edgar F. Codd）提出的规则，数据库管理系统应视末尾空格在比较中是有效的，但SQL Server在实际处理时，表现并不一致，这取决于我们使用的字符串类型和排序规则，对于最常见的VARCHAR类型，在大多数默认的排序规则下，SQL Server在进行等值比较（=）或使用LIKE进行模式匹配时，默认是会忽略字符串末尾的空格的，这意味着，查询 WHERE name = 'John' 可能会把数据库中实际存储为 'John '（后面有空格）的记录也找出来，如果你使用的是NVARCHAR类型，或者特定的区分空格的排序规则，情况就完全不同了，它会严格比较空格，更让人困惑的是，当使用DATALENGTH函数时，它会返回字符串的字节数，对于VARCHAR，一个空格是一个字节，'John'返回4，'John '返回5；但对于NVARCHAR，一个字符占两个字节，而LEN函数的行为又和等值比较类似，默认会截掉末尾的空格后再计算长度，LEN('John ')的结果是4，这种不一致性非常容易导致在数据清洗、去重或条件判断时出现意想不到的结果。

是关于字符串拼接的陷阱，在老版本SQL Server（2012之前）中，我们大量使用运算符来拼接字符串，但这个操作有个巨大的隐患：当拼接的任何一个操作数为NULL时，整个表达式的结果就会变成NULL，这被称为“NULL传染性”，你想把姓氏和名字拼接成全名：SELECT LastName + ', ' + FirstName AS FullName FROM Employees，如果某位员工的FirstName字段恰好是NULL，那么这位员工的FullName结果就不是预期的'LastName, '，而是直接变成NULL，整个名字就“消失”了，为了避免这个问题，我们必须使用ISNULL或COALESCE函数对每个可能为NULL的字段进行包裹，写成ISNULL(LastName, '') + ', ' + ISNULL(FirstName, '')，这样非常繁琐，虽然SQL Server 2012及以后版本引入了更强大的CONCAT函数，它能自动将NULL视为空字符串处理，大大简化了写法（CONCAT(LastName, ', ', FirstName)），但很多遗留系统仍然在使用旧的号方式,这个坑依然广泛存在。

第三个需要留神的细节是，在WHERE子句中使用LIKE进行模糊查询时，通配符的转义问题，我们都知道代表任意多个字符，_代表一个任意字符，但如果你想搜索的字符串本身就包含或_这些符号时，比如查找备注信息中包含"完成度50%"的记录，如果直接写LIKE '%50%%'，数据库会将其解析为“前面任意字符，接着是50，再接着任意字符”，这样会错误地匹配到"完成度50%"，"完成度100%"，"任务50个"等等，因为最后一个匹配了任何字符，正确的做法是使用ESCAPE关键字来指定一个转义字符，可以写成LIKE '%50!%%' ESCAPE '!'，这里的被指定为转义符，它告诉数据库紧跟在它后面的不再代表通配符，而是普通的百分号字符,忘记转义是导致模糊查询结果过滥的一个常见原因。

第四个坑与字符串截取函数SUBSTRING有关，它的语法是SUBSTRING(expression, start, length)，这里容易出错的有两点：一是start参数，它的起始位置是1，而不是像某些编程语言那样从0开始，如果你误写为0，SQL Server不会报错，但会从第一个字符之前开始截取，可能返回空字符串或奇怪的结果，二是当start值加上length值超过了字符串的实际长度时，SUBSTRING函数不会报错，而是会返回从start位置开始到字符串末尾的所有字符，这个行为虽然不算错误，但如果你预期它会返回固定长度的字符串或者会报错,那么在处理数据时可能会因为结果长度不一致而引发后续问题。

还有一个关于字符集和排序规则的全局性细节，当你的数据库是区分大小写（Case-Sensitive）的排序规则时，'Apple'和'apple'会被认为是两个不同的字符串，在这样的数据库上，你的WHERE条件就必须严格匹配大小写，反之，如果是不区分大小写的排序规则，它们则被认为是相同的，这个问题在数据库迁移（比如从一台不区分大小写的服务器迁移到另一台区分的服务器）时尤其突出，可能导致大量查询突然失效或结果异常，同样，排序规则还决定了重音是否敏感，比如'cafe'和'café'是否相同，在编写跨不同环境运行的SQL脚本时,必须考虑到排序规则可能带来的影响。

SQL Server的字符串操作看似基础，但上述这些细节——末尾空格的比较行为、NULL值在拼接中的传染性、LIKE通配符的转义、SUBSTRING函数的边界处理，以及排序规则对比较结果的深远影响——都需要我们在实际工作中格外留神，通过充分的测试来避免掉入陷阱,确保数据处理的准确性。