SQL优化需避免ORDER BY中多层函数、动态排序及大OFFSET分页，应物化计算列、用游标分页、确保索引顺序与ORDER BY严格一致，并慎用动态拼接以防止参数嗅探失效。
ORDER BY 子句里别直接套多层函数调用
SQL Server 和 MySQL 在执行 ORDER BY 时，如果排序字段是像 UPPER(name)、DATEADD(day, 1, created_at) 这类计算表达式，优化器大概率无法利用索引，还会强制走 Sort 算子——这意味着每行都要进内存排序，数据量一过百万，tempdb 压力和 CPU 消耗会陡增。
实操建议：
- 把常用计算逻辑提前物化：比如经常按大写姓名排序，就在表里加个
name_upper计算列（SQL Server 支持PERSISTED），或建函数索引（MySQL 8.0+ / PostgreSQL） - 避免在
ORDER BY中用CASE WHEN实现动态权重排序，改用预计算的排序权重列 + 索引 - 确认执行计划里是否出现
Warning: No Join Predicate或高开销的Sort节点——这是最直接的信号
分页场景下 OFFSET 超过 10000 就该换方案
OFFSET 10000 ROWS FETCH NEXT 50 ROWS ONLY 看似简洁，但 SQL Server 和 PostgreSQL 都得先扫描并跳过前 10000 行；MySQL 5.7 更惨，LIMIT 10000,50 仍要构造完整结果集再截断。内存占用和响应延迟随偏移量线性增长。
实操建议：
- 用游标分页替代：基于上一页最后一条记录的
id或created_at做条件过滤，例如WHERE created_at > '2024-01-01' AND id > 12345 ORDER BY created_at, id LIMIT 50 - 对非实时要求高的报表，把分页结果缓存到临时表，加
PRIMARY KEY或CLUSTERED INDEX，后续分页直接查这个表 - 禁止在存储过程中拼接动态
OFFSET参数，尤其当参数来自前端未校验输入时——可能触发全表扫描
多个 ORDER BY 字段顺序必须和复合索引列顺序严格一致
你建了索引 CREATE INDEX IX_user_status_score ON users(status, score DESC)，但查询写成 ORDER BY score DESC, status，SQL Server 就不会复用这个索引，照样触发排序。索引能跳过排序的前提是：ORDER BY 的字段顺序、升降序、以及是否包含所有等值过滤字段，三者全部匹配。
实操建议：
- 检查执行计划中
Ordered属性是否为True；如果是False，说明引擎没用索引做排序，而是自己排 - 等值条件字段（如
WHERE status = 1）必须放在ORDER BY最前面，才能让索引生效；否则即使字段名对，顺序错也白搭 - MySQL 8.0+ 支持降序索引，但 SQL Server 的
DESC只影响叶节点物理顺序，不改变索引可覆盖的排序方向逻辑
存储过程里动态拼接 ORDER BY 容易引发参数嗅探失效
用 EXEC sp_executesql 拼 @orderby 参数时，SQL Server 默认按第一次执行的参数值生成执行计划并缓存。如果第一次是 ORDER BY name，第二次传 ORDER BY created_at DESC，很可能复用旧计划导致排序性能崩塌——因为计划里没预设新字段的索引路径。
实操建议：
- 拆成多个固定排序逻辑的存储过程，而不是一个“万能”过程；用应用层路由，比 SQL 层动态更可控
- 若必须动态，给每个关键排序分支加
OPTION (RECOMPILE)，代价是编译开销，但避免错误计划复用 - 警惕
ISNULL(@sort_col, 'id')这类写法——它会让优化器彻底放弃索引推断，直接走全表扫描+排序
复杂排序真正难的不是语法，是让优化器相信“这列我已经排好了”，而不是每次都在 tempdb 里重新堆一遍。索引设计、参数绑定方式、甚至客户端传参格式，都可能悄悄破坏这个信任链。
