为何在T-SQL中按LEN([FieldName])排序时字符串拼接失败？

问题场景 #

需要将一组VARCHAR类型的值拼接为单个VARCHAR(MAX)字符串，并按字符长度降序排列。实际实现时发现，直接在ORDER BY子句中使用LEN()函数会导致拼接失败，改用预先存储长度值的字段排序则能正常工作。

测试环境准备 #

创建表变量并初始化数据：

DECLARE @FOO TABLE
(
    [TextValue] VARCHAR(100),
    [TextLength] INT
)

INSERT INTO @FOO ([TextValue])
VALUES ('First')

INSERT INTO @FOO ([TextValue])
VALUES ('Second')

UPDATE @FOO 
SET [TextLength] = LEN([TextValue])

初始数据顺序为First（长度5）在前，Second（长度6）在后。

两种尝试的对比 #

尝试1：ORDER BY LEN([TextValue]) DESC #

执行以下拼接代码：

DECLARE @CONCAT VARCHAR(MAX)

SET @CONCAT = NULL

SELECT @CONCAT = CASE 
                     WHEN @CONCAT IS NULL
                         THEN [TextValue]
                         ELSE @CONCAT + ' ' + [TextValue] 
                 END
FROM @FOO
ORDER BY LEN([TextValue]) DESC

SELECT @CONCAT

结果：仅返回First，拼接失败。

尝试2：ORDER BY预计算的[TextLength]字段 #

执行以下拼接代码：

DECLARE @CONCAT VARCHAR(MAX)

SET @CONCAT = NULL

SELECT @CONCAT = CASE 
                     WHEN @CONCAT IS NULL
                         THEN [TextValue]
                         ELSE @CONCAT + ' ' + [TextValue] 
                 END
FROM @FOO
ORDER BY [TextLength] DESC

SELECT @CONCAT

结果：正常返回Second First。

原因解析 #

这种通过SELECT对变量赋值实现字符串拼接的方式属于非标准SQL技巧，SQL Server官方文档并未保证该写法的执行顺序和结果稳定性：

1. 当ORDER BY子句中使用LEN()这类函数时，查询优化器可能调整执行计划——优先完成变量赋值操作，再对结果集进行排序。这会导致变量仅被单条记录赋值，而非按排序后的顺序依次累加。
2. 改用预计算的[TextLength]字段时，排序基于表中已存储的固定值，优化器能明确确定排序后的行顺序，从而按该顺序依次对变量进行累加赋值，最终得到正确的拼接结果。

推荐方案 #

SQL Server 2017及以上版本推荐使用官方支持的STRING_AGG函数实现排序拼接，写法简洁且结果稳定：

SELECT STRING_AGG(TextValue, ' ') WITHIN GROUP (ORDER BY LEN(TextValue) DESC)
FROM @FOO

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