正确做法是为每个排序字段和方向组合单独写CASE分支，确保所有分支返回同类型值，并避免字符串拼接以防注入；各分支需显式指定ASC/DESC，且NULL值会影响排序位置。
用 CASE WHEN 实现动态排序时，ORDER BY 里不能直接写参数
很多人想把排序字段做成变量（比如前端传 sort_field 和 sort_dir），然后在 ORDER BY 里用 CASE WHEN 拼，结果报错或排序失效。根本原因是：SQL 标准不允许 ORDER BY 中的表达式返回不同类型（比如一会儿是 INT，一会儿是 VARCHAR），而且数据库优化器通常不支持对 CASE 返回值做稳定排序。
正确做法是为每个可能的排序字段单独写一个 CASE 分支，并确保所有分支返回同类型、可比较的值：
ORDER BY CASE WHEN @sort_field = 'id' AND @sort_dir = 'ASC' THEN id END ASC, CASE WHEN @sort_field = 'id' AND @sort_dir = 'DESC' THEN id END DESC, CASE WHEN @sort_field = 'name' AND @sort_dir = 'ASC' THEN name END ASC, CASE WHEN @sort_field = 'name' AND @sort_dir = 'DESC' THEN name END DESC
注意点：
-
@sort_field和@sort_dir必须是 SQL 变量（如 MySQL 的用户变量）或绑定参数（如 JDBC 的?），不能是字符串拼接进 SQL —— 否则有注入风险 - 每个
CASE分支只控制一个字段+方向的排序权重，NULL 值会被排在最后（ASC）或最前（DESC），不影响其他分支 - 性能上，这种写法无法利用索引加速排序，大数据量时建议改用应用层拼接 SQL 或生成式视图
WHERE 条件中嵌套 CASE WHEN 容易导致索引失效
有人写 WHERE CASE WHEN @filter_type = 'active' THEN status ELSE 1 END = 1 来统一过滤逻辑，这看似简洁，实则让优化器无法识别真实过滤条件，几乎必然走全表扫描。
更安全、高效的做法是用布尔逻辑组合条件，让优化器能下推判断：
WHERE (@filter_type IS NULL OR @filter_type = 'all') OR (@filter_type = 'active' AND status = 'active') OR (@filter_type = 'draft' AND status = 'draft')
或者用 UNION ALL 拆分（适用于分支少、逻辑差异大的场景）：
SELECT * FROM posts WHERE @filter_type = 'active' AND status = 'active' UNION ALL SELECT * FROM posts WHERE @filter_type = 'draft' AND status = 'draft'
关键区别：
-
CASE在WHERE里是表达式计算，数据库必须对每行求值；而布尔短路逻辑允许优化器提前剪枝 - 如果字段上有索引（如
status），第二种写法大概率能命中索引范围扫描 - PostgreSQL 支持
IMMUTABLE函数 + 表达式索引缓解该问题，但 MySQL 不支持类似机制
MySQL 中用 CASE WHEN 做动态列计算要小心隐式类型转换
当 CASE WHEN 分支返回不同类型（比如 THEN 100 和 THEN 'N/A'），MySQL 会强制转成字符串，导致数值比较出错或排序错乱。
例如这个常见错误：
SELECT
CASE
WHEN score >= 90 THEN 'A'
WHEN score >= 80 THEN 'B'
ELSE score -- 这里是 INT，和前面的 VARCHAR 冲突
END AS grade
FROM students结果所有值都变成字符串，score 被转成 '85'，后续想按数字统计就麻烦了。修复方式只有两个：
- 全部分支保持同一类型：用
ELSE 'N/A'替代ELSE score - 需要数值上下文时，用
CAST显式统一：如ELSE CAST(score AS CHAR)或反过来THEN CAST('A' AS SIGNED)（但后者语义不合理） - 真正需要混合类型输出的场景，应该在应用层处理，而不是强塞进 SQL
PostgreSQL 的 ORDER BY + CASE WHEN 更灵活，但仍有陷阱
PostgreSQL 允许在 ORDER BY 里用 CASE 返回任意类型，也支持 NULLS FIRST/LAST 控制空值位置，看起来比 MySQL 友好。但要注意它对 COLLATE 和排序规则的处理：
比如对中文字段排序：
ORDER BY
CASE WHEN @sort_by = 'title_zh'
THEN title COLLATE "zh_CN.utf8"
END如果没显式指定 COLLATE，默认用数据库 locale，可能导致拼音排序不准。另外，PostgreSQL 会为每个 CASE 分支生成独立的排序键，若分支多、数据大，内存占用明显上升。
实用建议：
- 优先用
pg_catalog.pg_collation_for查当前字段实际排序规则，避免硬编码 - 避免在
CASE里调用函数（如UPPER(title)），否则无法走函数索引 - 如果只是切换 ASC/DESC，用
ORDER BY field * CASE WHEN @dir = 'DESC' THEN -1 ELSE 1 END更轻量（仅限数值字段）
动态排序和条件过滤看似只是语法技巧，实际牵扯到执行计划生成、索引选择、类型系统约束三层问题。多数线上慢查询，根源不在写法“不够酷”，而在没意识到数据库不是万能表达式引擎——它最擅长的是确定性路径，而不是运行时猜意图。
