业务系统的列表页面几乎都离不开排序功能，用户点击表头就希望按对应的列重新排序。如果每一种排序组合都写一条SQL，存储过程会越写越多，维护起来非常痛苦。其实在存储过程内部利用CASE WHEN表达式，就可以让ORDER BY的排序列根据传入参数动态变化，一条存储过程搞定所有排序需求。本文围绕这个思路，从原理到完整实现逐一展开。
为什么ORDER BY不能直接使用变量
很多初学者会想当然地写出下面这样的代码：
CREATE PROCEDURE GetUsers
@SortColumn NVARCHAR(50)
AS
BEGIN
SELECT Id, UserName, Age, CreateTime
FROM Users
ORDER BY @SortColumn; -- 这行会报错
END
这种写法在SQL Server中会直接抛出错误，提示SELECT语句中包含无效的列名或者语法不兼容。原因在于ORDER BY后面接的参数被当作一个表达式求值，而不是一个列引用。数据库引擎在编译阶段就要确定排序依据的物理列，而变量的值要到运行阶段才确定，两者天然冲突。
理解了这个限制，就能明白为什么常用的解决方案有两类：一类是用动态SQL拼接字符串再通过EXEC执行，另一类就是本文重点介绍的CASE WHEN静态写法。前者灵活但存在SQL注入风险，后者把所有排序可能性显式写在SQL里，由优化器自行选择，安全性更好。
CASE WHEN实现动态排序的核心原理
CASE WHEN的思路是：把用户传入的排序参数翻译成多个并列的排序表达式，每个表达式内部用CASE判断当前参数值，只有匹配的那个分支会返回真实的列值，其他分支返回固定值。来看一个基础版本：
CREATE PROCEDURE GetUsersSorted
@SortColumn NVARCHAR(50),
@SortDirection NVARCHAR(10) = 'ASC'
AS
BEGIN
SELECT Id, UserName, Age, CreateTime
FROM Users
ORDER BY
CASE WHEN @SortColumn = 'UserName' THEN UserName END ASC,
CASE WHEN @SortColumn = 'Age' THEN Age END ASC,
CASE WHEN @SortColumn = 'CreateTime' THEN CreateTime END ASC;
END
当传入的@SortColumn值为UserName时，第一个CASE表达式返回每行的用户名，第二、第三个表达式因为条件不满足返回NULL。NULL在升序排序中会被排在一起，不影响主排序的结果。这样三条排序规则叠加，实际生效的只有匹配的那一条。
这里有一个非常关键的细节：排序方向不能也用CASE来做。如果你试图写CASE WHEN @SortDirection = 'DESC' THEN UserName END DESC，语法上就过不去，因为ASC和DESC是关键字，不能动态生成。要支持升降序切换，需要为同一个列写两条CASE表达式，一条固定ASC，一条固定DESC，再借助一个方向参数让其中一条失效。
支持升降序切换和分页的完整实现
升降序切换的技巧是让失效的那个排序表达式返回一个对所有行都相同的常量，常量排序等于没有排序。下面是生产环境常用的完整版本，同时包含分页逻辑：
CREATE PROCEDURE GetUserPage
@PageIndex INT = 1,
@PageSize INT = 20,
@SortColumn NVARCHAR(50) = 'CreateTime',
@SortDirection NVARCHAR(10) = 'DESC'
AS
BEGIN
-- 规范化方向参数，只允许两个合法值
DECLARE @Dir INT = CASE WHEN @SortDirection = 'DESC' THEN 1 ELSE 0 END;
;WITH PageData AS
(
SELECT Id, UserName, Age, Amount, CreateTime,
ROW_NUMBER() OVER (
ORDER BY
CASE WHEN @SortColumn = 'UserName' AND @Dir = 0 THEN UserName END ASC,
CASE WHEN @SortColumn = 'UserName' AND @Dir = 1 THEN UserName END DESC,
CASE WHEN @SortColumn = 'Age' AND @Dir = 0 THEN Age END ASC,
CASE WHEN @SortColumn = 'Age' AND @Dir = 1 THEN Age END DESC,
CASE WHEN @SortColumn = 'Amount' AND @Dir = 0 THEN Amount END ASC,
CASE WHEN @SortColumn = 'Amount' AND @Dir = 1 THEN Amount END DESC,
CreateTime DESC -- 默认兜底排序，保证分页结果稳定
) AS RowNum
FROM Users
WHERE IsDeleted = 0
)
SELECT Id, UserName, Age, Amount, CreateTime
FROM PageData
WHERE RowNum BETWEEN (@PageIndex - 1) * @PageSize + 1
AND @PageIndex * @PageSize;
END
这个版本有几个值得注意的设计。首先是参数白名单的思想：虽然用了CASE WHEN，但@SortColumn的值永远不拼进SQL字符串，从根源上杜绝了注入。其次是每个排序列配对了ASC和DESC两条表达式，通过@Dir参数二选一激活。最后加了CreateTime作为兜底排序，这很重要，因为当排序列存在大量重复值时，没有兜底排序会导致分页结果在不同请求之间不稳定，出现重复或遗漏数据的现象。
另外要提醒一个数据类型陷阱：不同CASE表达式之间如果放在同一个ORDER BY位置，SQL Server要求它们返回类型可以隐式转换。上面把UserName、Age、Amount分别放在独立的排序位置上，就避免了字符串和数字混合比较的问题。如果把所有列都塞进一个CASE表达式，像CASE @SortColumn WHEN 'Age' THEN Age WHEN 'UserName' THEN UserName END这样，Age会被隐式转成字符串，排序结果就完全乱了。按列拆开写是必须坚持的原则。
CASE WHEN与动态拼接SQL的对比选择
另一条技术路线是用EXEC执行拼接出来的SQL字符串，它同样能实现动态排序：
CREATE PROCEDURE GetUsersDynamic
@SortColumn NVARCHAR(50),
@SortDirection NVARCHAR(10)
AS
BEGIN
-- 必须自己维护白名单，否则有注入风险
IF @SortColumn NOT IN ('UserName', 'Age', 'CreateTime')
SET @SortColumn = 'CreateTime';
IF @SortDirection NOT IN ('ASC', 'DESC')
SET @SortDirection = 'ASC';
DECLARE @Sql NVARCHAR(MAX);
SET @Sql = 'SELECT Id, UserName, Age, CreateTime
FROM Users
ORDER BY ' + @SortColumn + ' ' + @SortDirection;
EXEC(@Sql);
END
两种方案各有优劣。动态拼接的优势是排序逻辑直观，SQL语句干净，而且优化器能拿到真实的列名，有可能利用索引避免排序操作，数据量大时性能优势明显。缺点是SQL注入风险必须靠白名单自己拦，字符串拼接多了以后代码可读性下降，执行计划缓存也会因为语句文本变化而命中率降低。
CASE WHEN的优势则是安全、结构固定、执行计划缓存稳定，一条语句适配所有排序组合。代价是SQL写起来啰嗦，而且CASE表达式可能让优化器难以利用索引，常常触发Sort运算符全量排序。经验上的选择标准是：中小数据量的列表查询（几十万行以内）优先用CASE WHEN，简单省心；数据量到千万级、排序性能成为瓶颈时，改用白名单校验加动态拼接，或者干脆用sp_executesql配合参数化。无论选哪种，把排序列限制在白名单内这一步都不能省，这是动态排序方案安全的底线。