所有CASE分支返回值类型必须一致，否则SQL Server会强制隐式转换导致Conversion failed错误；应统一转为VARCHAR或同类型，数值字段用CONVERT(VARCHAR(50), col)，日期用CONVERT(VARCHAR(23), col, 126)，各分支须含ELSE且类型匹配。
SQL Server里ORDER BY + CASE报Conversion failed错误怎么办
直接结论：所有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默认按INT推断类型，把name全转成数字失败。
- 数值字段（如
id、price）统一用CONVERT(VARCHAR(50), col)转字符串，别依赖自动转换 - 日期字段（如
created_at）用CONVERT(VARCHAR(23), col, 126)格式化为ISO8601字符串，保证可比性 - 每个
CASE分支都必须有ELSE，且类型匹配，例如ELSE ''或ELSE 0，避免NULL导致整列排序失效
如何安全控制升序/降序方向（不拼ASC/DESC字符串）
传@sort_dir VARCHAR(4)然后拼进ORDER BY是高危操作：既无法参数化，又触发执行计划缓存失效，还可能被注入。
正确做法是用@sort_dir BIT（0=ASC，1=DESC），配合正负号或双分支控制：
- 数值字段可用
CASE WHEN @sort_dir = 1 THEN -1 ELSE 1 END * CASE WHEN @sort = 'price' THEN price ELSE 0 END，但注意DESC要加在整行末尾 - 字符串字段得拆成两个独立
CASE：CASE WHEN @sort_dir = 1 THEN name END DESC, CASE WHEN @sort_dir = 0 THEN name END ASC - 别在一个
CASE里混用ASC/DESC——SQL Server不支持动态关键字
WHERE条件动态过滤时，ISNULL(@param, column)为什么让索引失效
WHERE status = ISNULL(@status, status)看着简洁，但SQL Server无法对表达式列做索引Seek，只能走Scan，性能断崖下跌。
真正能走索引的写法是用OR配合IS NULL判断：
-
WHERE (@status IS NULL OR status = @status)——当@status有值时，优化器有机会走status上的索引Seek - 多个条件叠加（如
@category、@type）后，执行计划可能退化成Scan；若过滤字段区分度低（比如status只有3个值），建议加OPTION (RECOMPILE) - 白名单校验不能少：
@sort参数值必须限定在预设字段内（如'name'、'created_at'、'status'），否则直接RAISERROR退出
为什么别用字符串拼接构造ORDER BY
拼接@sql = 'ORDER BY ' + @sort_column不是“懒”，是根本不可取：它让SQL Server拒绝缓存执行计划，每次都是编译新计划，CPU和内存压力陡增；更严重的是，一旦@sort_column被恶意篡改，就是典型SQL注入漏洞。
真正可控的动态排序，必须把逻辑“硬编码”进语句结构里——靠CASE分支、靠白名单、靠类型对齐。哪怕多写几行，也比埋下性能和安全双雷强。
复杂点在于字段类型混杂时的转换取舍：转字符串排序直观但不符合数值语义；保持原类型又得为每种类型单独设计分支。实际项目里，往往得按业务场景权衡，而不是指望一套模板通吃。
