SQL标准禁止在ORDER BY中用CASE WHEN返回'ASC'/'DESC'字符串来动态控制排序方向，因CASE只能改变排序值而非方向；可行方案是数值取负、日期转天数取负或谨慎用REVERSE，但更推荐应用层判断后拼接确定的ORDER BY子句。
为什么直接拼接 ASC/DESC 会报错
SQL 标准不允许在 ORDER BY 子句里用 CASE WHEN 返回字符串（如 'ASC' 或 'DESC'）来动态控制排序方向——这会被解析为字面量排序字段，而不是语法关键字。常见错误是：ORDER BY CASE WHEN @dir = 'desc' THEN col END DESC, CASE WHEN @dir = 'asc' THEN col END ASC，看似聪明，实则逻辑断裂：两分支不能共存，且 NULL 分支会破坏排序稳定性。
CASE WHEN 只能控制「排序值」，不能控制「排序方向」
标准 SQL 中，CASE WHEN 在 ORDER BY 里只能返回可比较的表达式（如数字、字符串、日期），用于改变「按什么值排」，而非「升序还是降序」。真正可行的做法是利用正负号反转数值顺序，或用字符串翻转技巧处理文本：
- 对数字列：
ORDER BY CASE WHEN @dir = 'desc' THEN -score ELSE score END - 对日期列：
ORDER BY CASE WHEN @dir = 'desc' THEN -DATEDIFF(day, '1970-01-01', created_at) ELSE DATEDIFF(day, '1970-01-01', created_at) END - 对字符串列（需谨慎）：
ORDER BY CASE WHEN @dir = 'desc' THEN REVERSE(name) ELSE name END—— 注意：仅当字符集支持且无重音/多字节问题时才勉强可用；更安全的方式是用两次查询或应用层处理
PostgreSQL / SQL Server 支持动态 ORDER BY 的替代写法
某些数据库提供更灵活的语法，绕过 CASE 的限制：
- PostgreSQL 允许在
ORDER BY中使用布尔表达式：ORDER BY (CASE WHEN @dir = 'desc' THEN col END) DESC, (CASE WHEN @dir = 'asc' THEN col END) ASC—— 但注意：两个分支必须互斥，且未命中分支返回 NULL，可能影响结果顺序 - SQL Server 2022+ 支持
IIF，语义等价但不解决本质问题；真正可靠的是用动态 SQL：EXEC sp_executesql N'SELECT * FROM t ORDER BY col ' + @dir，前提是 @dir 已白名单校验（如只允许'ASC'或'DESC'） - MySQL 8.0+ 同样依赖动态 SQL 或应用层判断，没有原生「方向参数化」语法
最稳妥的工程实践：别硬刚 SQL 层的排序方向
在真实系统中，把排序方向交给 SQL 动态控制，往往得不偿失：
- 预编译语句（Prepared Statement）无法缓存不同
@dir值的执行计划，导致 plan cache 冗余甚至失效 - ORM（如 SQLAlchemy、MyBatis）通常已封装好安全的排序参数注入，比手写 CASE 更可控
- 前端传来的
sort=price&order=desc，更适合在服务端做 if 判断后拼出确定的ORDER BY price DESC，再交给数据库——既清晰又利于索引利用
真正容易被忽略的是：即使 CASE 表达式能跑通，它大概率让数据库放弃使用对应列上的索引进行排序，转而走 filesort。这点在数据量稍大时立刻暴露。
