SQL Server动态排序应禁用字符串拼接ORDER BY，改用白名单+CASE表达式；升序降序用BIT参数控制；多字段排序需类型统一并显式处理NULL；WHERE动态过滤避免ISNULL，宜用OR+IS NULL或OPTION(RECOMPILE)。
SQL Server 存储过程里不能拼接 ORDER BY 字段名
直接用 @sort_column 拼进 SQL 字符串（比如 'ORDER BY ' + @sort_column）是危险且低效的。SQL Server 不会缓存执行计划，每次调用都触发编译；更严重的是，这开了 SQL 注入口——哪怕参数来自内部系统，也别赌它永远干净。
正确做法是把所有允许排序的字段列在白名单里，用 CASE 表达式硬编码进 ORDER BY。优化器能预编译、走索引（如果条件匹配）、且类型可控。
-
@sort_by类型设为VARCHAR(32)，只接受预设值：比如'name'、'created_at'、'status' - 每个字段分支必须返回相同类型：全转
VARCHAR或全保持原类型；混用INT和DATETIME会导致 SQL Server 报错Conversion failed when converting the varchar value to data type int - 别在
CASE里调用GETDATE()或NEWID()，每行重算，执行计划失效
升序降序要用 BIT 参数控制正负号
传字符串 'ASC'/'DESC' 进存储过程，再拼进语句，同样踩坑。T-SQL 的 ORDER BY 不支持运行时解析方向关键词。
标准解法是用一个 @sort_desc BIT 参数（0=升序，1=降序），在外层套一层 CASE 控制符号：
ORDER BY
CASE WHEN @sort_desc = 1 THEN -1 ELSE 1 END *
CASE @sort_by
WHEN 'id' THEN id
WHEN 'age' THEN CAST(age AS BIGINT)
WHEN 'name' THEN 0 -- 字符串不能乘，得换招
END
注意：name 这类字符串字段不能直接参与数值运算。稳妥做法是拆成两个独立 CASE 分支，分别处理方向：
- 升序分支：
CASE @sort_by WHEN 'name' THEN name END ASC - 降序分支：
CASE @sort_by WHEN 'name' THEN name END DESC - 最终写成：
CASE @sort_by WHEN 'name' THEN name END ASC, CASE @sort_by WHEN 'name' THEN name END DESC—— 看似冗余，但 SQL Server 允许，且能正确识别方向
多字段动态排序要分层嵌套 CASE
业务常要求“状态为提交的按创建时间倒序，状态为审核的按开始时间正序”，这不是单个字段切换，而是排序逻辑随状态变化。这时候不能只靠一个 @sort_by 控制字段，得用状态字段做第一层 CASE，再在每个分支里决定用哪个时间字段和方向。
关键约束：每个 WHEN 分支返回值类型必须一致。比如都用 UNIX_TIMESTAMP() 转成整数，或都用 COALESCE(t.field, '1970-01-01') 填 NULL 后统一转 DATETIME。
- 错误写法：
CASE WHEN status='Apply' THEN create_time WHEN status='Review' THEN start_time END DESC—— 类型不一致，SQL Server 可能静默截断或报错 - 正确写法：
CASE WHEN status='Apply' THEN DATEDIFF(SECOND, '1970-01-01', create_time) WHEN status='Review' THEN DATEDIFF(SECOND, '1970-01-01', start_time) ELSE 0 END DESC - NULL 值必须显式填充，否则未匹配状态的行会因返回 NULL 被排到最前（ASC）或最后（DESC），破坏业务顺序
WHERE 条件动态过滤别用 ISNULL() 包裹字段
很多人写 WHERE status = ISNULL(@status, status) 图省事，但这会让 SQL Server 放弃索引 Seek，强制走 Scan。哪怕 @status 有值，优化器也无法利用 status 上的索引。
真正兼容索引的方式是用 OR + IS NULL 判断：
WHERE (@status IS NULL OR status = @status) AND (@category IS NULL OR category = @category)
但要注意：当多个 OR 条件叠加、且字段区分度低（比如 status 只有 3 个值），执行计划可能退化为全表扫描。此时可加 OPTION (RECOMPILE)，让每次执行都重生成计划 —— 尤其适合参数组合变化频繁的场景。
最容易被忽略的是：动态排序本身无法走索引。无论你建了多少字段索引，只要 ORDER BY 里出现表达式（包括 CASE），就大概率触发 filesort。数据量超百万行时，别硬扛，提前物化排序字段更实际。
