能用，但所有CASE分支返回值必须同类型，否则SQL Server会强制隐式转换导致排序错乱或报Conversion failed错误；未写ELSE时默认补NULL，引发NULL排序位置不固定。
SQL Server 存储过程里用 CASE WHEN 做动态排序，字段类型必须统一
直接结论：能用，但所有 CASE 分支返回的值必须是同一数据类型，否则 SQL Server 会强制隐式转换，轻则排序错乱，重则报 Conversion failed when converting the varchar value to data type int。
常见错误写法：ORDER BY CASE WHEN @sort = 'id' THEN id WHEN @sort = 'name' THEN name END——如果 id 是 INT、name 是 VARCHAR，SQL Server 会把 id 全转成字符串排，而字符串比较 “10”
实操建议：
- 数值类字段（如
id、price）统一用CONVERT(VARCHAR(50), col)转字符串，别依赖自动转换 - 日期类字段（如
created_at）用CONVERT(VARCHAR(23), col, 126)格式化为 ISO8601 字符串，保证可比性 - 所有分支必须有
ELSE ''或ELSE 0，避免 NULL 导致整列排序失效（SQL Server 默认NULLS FIRST）
升序降序不能靠传 'ASC'/'DESC' 字符串控制
传 @sort_dir VARCHAR(4) 然后拼进 ORDER BY 是高危操作：既无法参数化，又触发执行计划缓存失效，还可能被注入。
正确做法是用 @sort_dir BIT（0=ASC，1=DESC），配合正负号控制排序方向：
ORDER BY CASE WHEN @sort_dir = 1 THEN -1 ELSE 1 END * CASE WHEN @sort = 'price' THEN price ELSE 0 END DESC, CASE WHEN @sort_dir = 0 THEN price ELSE 0 END ASC
但注意：上面这种写法只适用于数值字段；字符串字段得换思路——用两层 CASE 包裹，外层控制是否倒序，内层取原值：
CASE WHEN @sort_dir = 1 THEN name END DESCCASE WHEN @sort_dir = 0 THEN name END ASC
SQL Server 会把两个条件合并为一个排序键，且保持原生类型不转换。
WHERE 条件动态过滤时，OR + IS NULL 比 ISNULL() 更利于索引 Seek
很多人写 WHERE status = ISNULL(@status, status)，看着简洁，但 SQL Server 无法对表达式列做索引 Seek，只能走 Scan。
真正能保留索引能力的写法是：
WHERE (@status IS NULL OR status = @status) AND (@category IS NULL OR category = @category)
但要注意边界情况：
- 当
@status和@category都为 NULL 时，条件恒真，执行计划可能退化为全表 Scan - 如果字段区分度低（比如
status只有 3 个值），建议加OPTION (RECOMPILE)，让每次执行都重生成执行计划 - 多个 OR 条件叠加后，优化器可能放弃使用索引，可考虑为高频组合字段建复合索引
PostgreSQL 和 MySQL 的处理更宽松，但别因此放松校验
PostgreSQL 允许在 ORDER BY 中混用不同类型的字段（如 id 和 name），它会自动做隐式转换；MySQL 8.0+ 对 CASE 类型也更宽容。但这不意味着可以跳过字段白名单校验。
关键风险点始终在参数来源：
-
@sort必须限定在预设白名单内（如'id'、'name'、'created_at'），不能直接拼接用户输入 - 即使数据库支持动态字段名（如 PostgreSQL 的
USING子句），也不该在存储过程中开放任意字段排序——业务语义和权限控制必须前置 - JSONB 字段排序（如
data->>'price'）必须提前建函数索引，否则ORDER BY强制 Seq Scan
最易被忽略的是：CASE 表达式里没写 ELSE 分支时，SQL Server 默认补 ELSE NULL，而 NULL 在排序中位置不固定（取决于 SET ANSI_NULLS 设置），线上环境容易出现结果抖动。
