sql server动态排序应避免字符串拼接，改用白名单内字段的case表达式；升降序用bit参数配合正负号控制；where条件用or+is null保持索引seek能力。
SQL Server 里用 @order_by 参数做动态排序，别拼字符串
直接拼接 ORDER BY 字段名进 SQL 字符串，是绝大多数人踩的第一个坑——不仅有注入风险，SQL Server 还会拒绝缓存执行计划，每次都是编译新计划，性能掉得明显。
正确做法是用 CASE 表达式在 ORDER BY 中分支判断，把排序逻辑“硬编码”进语句结构里，让优化器能预编译。字段名必须限定在白名单内，参数只控制分支走向。
-
@order_by类型用VARCHAR(32)就够，值只能是'name'、'created_at'、'status'这类预设字段 - 每个可排序字段对应一个
CASE分支，类型要一致（比如都转成VARCHAR或都保持原类型），否则 SQL Server 会报Conversion failed when converting the varchar value to data type int - 升序降序不能靠传
'ASC'/'DESC'字符串来控制，得拆成两个参数：@sort_dir是BIT（0=ASC，1=DESC），再用CASE包两层：外层控制正负号，内层取字段值
WHERE 条件动态过滤，IS NULL 比 = @param 更安全
参数可能为空，想让它“不生效”，很多人写 WHERE status = ISNULL(@status, status)，看着简洁，实际会导致索引失效——SQL Server 无法对表达式列做 Seek。
更稳妥的是用 OR 配合 IS NULL 判断，让优化器有机会走索引 Seek，尤其当 @status 有值时：
WHERE (@status IS NULL OR status = @status) AND (@category IS NULL OR category = @category)
注意：多个 OR 条件叠加后，执行计划可能退化成 Scan，如果过滤字段区分度低（比如 status 只有 3 个值），建议加 OPTION (RECOMPILE) 让每次执行都重生成计划。
PostgreSQL 的 ORDER BY 动态写法和 SQL Server 不一样
PostgreSQL 支持在 ORDER BY 里直接用变量做字段名，但仅限于 USING 子句或函数内；存储过程里仍得靠 CASE，不过语法稍松：字段类型不必强一致，它会自动隐式转换。
- 不要用
EXECUTE FORMAT拼ORDER BY，除非你明确需要运行时字段名（比如日志表按月分表），否则没必要承担解析开销 - PostgreSQL 9.6+ 支持
NULLS FIRST/LAST，配合@sort_dir时，可以直接写ORDER BY name NULLS LAST，比 SQL Server 少一层CASE - 如果排序字段是 JSONB 内的路径（如
data->>'price'），记得加函数索引，否则ORDER BY会强制 Seq Scan
MySQL 8.0+ 的窗口函数让动态排序更轻量
MySQL 5.7 不支持动态 ORDER BY 参数，升级到 8.0 后，可以用 ROW_NUMBER() OVER (ORDER BY ...) 预先算好序号，再在外层 WHERE 筛选范围，比在存储过程中反复改 ORDER BY 更可控。
但要注意：窗口函数不能直接套在 ORDER BY 参数上，仍需白名单 + CASE，只是可以把排序逻辑下推到子查询里，主查询只负责分页或截断：
SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (
ORDER BY
CASE WHEN @order_by = 'name' THEN name END,
CASE WHEN @order_by = 'created_at' THEN created_at END
) rn
FROM products
WHERE (@status IS NULL OR status = @status)
) t WHERE rn BETWEEN @offset+1 AND @offset+@limit
这种写法在数据量大、排序字段无索引时，OVER() 依然会触发临时表和 filesort，不是银弹。
真正难处理的是多字段组合排序（比如先按状态、再按时间），这时候 CASE 嵌套容易出错，字段顺序一错，结果就偏了——最好把排序规则写死在注释里，和前端约定好字段名与优先级。
