当前位置：首页 > 问答 > 正文

SQL Server里换行到底怎么控制才算细粒度，换行那些事儿说不完

召安青
问答
2026-01-15 09:56:15
3

说到在SQL Server里控制换行，很多人可能觉得就是个CHAR(10)或者CHAR(13)的事儿，敲进去不就完了？但真要细究起来，想把换行控制得服服帖帖，还真有不少门道，远不是一两个字符那么简单，这确实是个“说不完”的话题。

最基础的,我们都知道换行符，在Windows系统里，一个标准的换行通常由两个字符组成：回车符（CARRIAGE RETURN, CR）和换行符（LINE FEED, LF），也就是我们常说的CRLF，对应ASCII码是CHAR(13) + CHAR(10)，比如你想在一个字符串里手动换行，就会这么写：（来源：常见SQL编程实践）

SELECT '第一行' + CHAR(13) + CHAR(10) + '第二行' AS MyText

而在Unix/Linux系统里，换行通常只用LF，也就是CHAR(10)，这个差异在你从不同系统导入导出数据时，就会成为第一个需要面对的“细粒度”问题，如果你的数据是从Linux系统来的文本文件，用BCP或者SSIS导入到SQL Server，可能会发现原本的换行变成了黑方块或者显示不正常，这就是因为换行符不匹配，这时候，处理导入导出工具的设置，识别源文件的换行符类型，就是最初步的细粒度控制。

但上面说的都是“硬换行”，是作为数据本身的一部分存储进去的，真正的“细粒度”控制，往往体现在查询结果的展示上，也就是我们怎么让查询结果以一种更易读的格式呈现，这里的关键在于，SQL Server Management Studio（SSMS）这个最常用的工具，它默认的网格输出模式，是为了紧凑地显示数据，而不是为了保持字符串里的换行格式。（来源：SSMS官方文档及用户实践观察）

你可能会遇到一个经典问题：我在一个VARCHAR或NVARCHAR字段里，明明存进去了CHAR(13)+CHAR(10)，为什么在SSMS的查询结果里，它还是显示成一行，没有换行？这不是你的SQL写错了，而是SSMS网格视图的“特性”，它会将换行符显示为空格，要想真正“看到”换行效果，你需要切换到“结果到文本”的模式（快捷键Ctrl+T），在文本输出模式下，你存储的换行符才会被正确解释并显示为真正的换行。

这就引出了第一个层次的细粒度控制：根据你的查看目的，选择正确的SSMS输出模式，如果你是要检查数据中是否包含正确的换行符，用文本模式；如果你是要做数据分析和浏览，网格模式更合适。

再往深一层,当我们不满足于简单的两行拼接，而是需要构建一个复杂的、包含多行信息的字符串时，控制换行就变得更讲究，动态生成一个HTML邮件内容，或者构建一个用于报表的长字符串，这时候，单纯用号连接会使得SQL语句变得难以阅读和维护。

SET @Body = '<html><body>您好：' + CHAR(13) + CHAR(10) + '您的订单信息如下：' + CHAR(13) + CHAR(10) + ... -- 非常冗长

为了提升代码的可读性和可控性,我们可以利用一些SQL Server的函数来实现更“细粒度”的格式化，CONCAT_WS函数（SQL Server 2017及以上版本引入）就是一个利器。（来源：Microsoft SQL Server官方文档 - CONCAT_WS函数）

SQL Server里换行到底怎么控制才算细粒度，换行那些事儿说不完

SELECT CONCAT_WS(CHAR(13) + CHAR(10), '第一行', '第二行', '第三行') AS FormattedText

CONCAT_WS的第一个参数是分隔符,这里我们指定为CRLF，这样，它会自动在每个字符串之间插入这个分隔符，这样做的好处是：代码更清晰，你不需要在每一段之间重复写+ CHAR(13) + CHAR(10) +；它自动处理NULL值，如果中间的某个字符串是NULL，它会忽略掉，而不会导致整个结果变成NULL，这比用号连接安全得多，这是一种在“构建阶段”的细粒度控制。

另一个常见的场景是,我们从多行记录中拼接成一个带换行的字符串，有一个订单明细表，我们想将某个订单的所有商品名称用换行符连接起来，形成一个摘要，早年我们可能用FOR XML PATH的技巧：（来源：SQL Server社区常见解决方案）

SELECT STUFF((SELECT CHAR(13) + CHAR(10) + ProductName FROM OrderDetails WHERE OrderID = 123 FOR XML PATH('')), 1, 2, '') AS ProductsList

这个语句的原理是利用FOR XML PATH将多行数据合并成一个XML片段，并在每行前加上换行符，然后用STUFF函数去掉最开头多余的那个换行符，这曾经是标准做法，需要对SQL有较深的理解才能写出和看懂。

SQL Server里换行到底怎么控制才算细粒度，换行那些事儿说不完

而在SQL Server 2017及以后版本，我们有了更强大、更直观的字符串聚合函数STRING_AGG。（来源：Microsoft SQL Server官方文档 - STRING_AGG函数）

SELECT STRING_AGG(ProductName, CHAR(13) + CHAR(10)) WITHIN GROUP (ORDER BY ProductID) AS ProductsList FROM OrderDetails WHERE OrderID = 123

STRING_AGG函数直接明了地表达了“用某个分隔符聚合字符串”的意图，并且支持WITHIN GROUP子句来排序，这使得对多行数据换行拼接的控制变得前所未有的简单和精细，你可以轻松指定分隔符（换行符），可以控制聚合的顺序，代码的可读性大大增强，这是“细粒度控制”在现代化SQL中的体现。

还不能忽略数据清洗时的换行符问题,有时，我们从外部系统接收的数据可能包含不必要的换行符（比如在字段中间），这些换行符可能会破坏数据的结构，给后续处理（如CSV导出）带来麻烦，这时候，我们需要“剔除”这些换行符，使用REPLACE函数就可以做到：（来源：数据清洗常见做法）

UPDATE MyTable SET Description = REPLACE(REPLACE(Description, CHAR(13), ' '), CHAR(10), ' ')

这个语句先后将回车符和换行符都替换成空格,这种“删除”或“替换”操作，是另一种意义上的细粒度控制，目的是让数据格式符合我们的规范。

所以你看,SQL Server里的换行，从最基础的字符知识，到SSMS的显示特性，再到代码编写的技巧（CONCAT_WS），以及多行聚合的高级方法（STRING_AGG），最后到数据清洗的处理，每一个环节都有值得琢磨的地方，要想真正做到“细粒度”控制，就不能只知其然（知道用CHAR(10)），而是要知其所以然，并根据不同的场景选择最合适、最优雅的工具和方法，这其中的细节，确实不是三言两语能说完的。