为何ORDER BY子句中列别名参与计算仅SQL Server失效

这是SQL Server对T-SQL的固有解析逻辑，不是bug，本质是SQL标准没有对「表达式内引用SELECT别名」的场景做强制要求，不同数据库选择了不同的实现策略。

SQL标准的规则边界 #

SQL标准确实允许ORDER BY引用SELECT里定义的列别名，但这个支持有明确边界：只有当别名作为独立的排序项单独出现时，才属于标准强制要求支持的范畴。如果别名被包裹在计算表达式、函数里，标准不要求数据库必须识别，各厂商可以自己决定要不要做兼容扩展。

SQL Server的解析优先级 #

SQL Server处理ORDER BY里的标识符时，严格按两步匹配：

1. 先去FROM/JOIN关联的所有源表里找有没有同名的原生列，找到就直接使用
2. 只有当排序项是完全独立的单个标识符，且第一步没找到对应原生列的时候，才会去SELECT列表里匹配定义的列别名

只要标识符不是单独出现，哪怕只是做最简单的空字符串拼接，解析器都不会走第二步的别名匹配逻辑，只会把它当源表原生列查找，找不到就直接报错。

你测试的三个场景刚好完全符合这个逻辑：

WITH data AS(
    SELECT *
    FROM (VALUES
        ('apple'),
        ('banana'),
        ('cherry'),
        ('date')
    ) AS x(item)
)
SELECT item AS s
FROM data
--  ORDER BY s;         -- OK：s是独立标识符，源表无s列，触发别名匹配
--  ORDER BY item + ''; -- OK：item是源表原生列，直接取列做计算
ORDER BY s + '';        -- 报错：s在表达式内部，不触发别名匹配，源表找不到s列

其他数据库的差异 #

你测试的PostgreSQL、MariaDB、SQLite、Oracle都在标准基础上做了功能扩展：解析ORDER BY里的表达式时，会递归检查表达式里的所有标识符，哪怕嵌在表达式内部，也会同时匹配SELECT列表的别名，所以不会报错。这个扩展属于厂商自主新增的兼容能力，不是SQL标准要求必须实现的，SQL Server至今没有加入这层解析逻辑，因此表现和其他数据库存在差异。

SQL Server里的规避方法 #

如果需要在排序表达式里使用SELECT定义的别名，两种通用写法都可以生效：

• 把带别名的查询包裹为子查询或者CTE，外层查询里别名和普通原生列没有区别，可以直接用在任意表达式中
• 不引用别名，直接在ORDER BY里重复书写SELECT中对应别名的计算逻辑

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