ORDER BY 必须写在最外层 SELECT 末尾才生效，CTE/子查询中无效；分页需加唯一排序键防结果不稳定；动态SQL拼接时注意 COLLATE 和类型匹配。
SQL Server 存储过程中 ORDER BY 不生效，根本不是“没写”，而是没写对位置或没覆盖所有分支路径。
存储过程里 ORDER BY 必须写在最终 SELECT 的末尾
很多人把 ORDER BY 写在子查询、CTE 或临时表插入语句里，比如：
WITH cte AS ( SELECT * FROM Employees ORDER BY Salary DESC -- ❌ 这里 ORDER BY 被忽略 ) SELECT * FROM cte;
SQL Server 明确规定：ORDER BY 在 CTE、视图、子查询中**不保证输出顺序**，除非它出现在最外层的 SELECT 语句末尾。否则优化器可能直接丢弃该子句。
- 只在最终返回客户端的那条
SELECT后加ORDER BY，才真正起效 - 如果用了
INSERT INTO #tmp ... SELECT ...，再SELECT * FROM #tmp，那第二个SELECT才是必须带ORDER BY的地方 - 动态 SQL 中的
ORDER BY必须拼在字符串末尾，且不能被注释或换行截断
带分页逻辑时 ORDER BY 必须配合唯一排序键
用 OFFSET-FETCH 或 ROW_NUMBER() 分页时，若 ORDER BY 字段存在重复值（比如多个员工薪资相同），SQL Server 可能每次返回不同行序——这不是 bug，是标准行为。
例如：
SELECT * FROM Employees ORDER BY Salary DESC OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY;
当有多条 Salary = 50000 的记录时，哪 5 条被选中不确定。
- 必须补一个唯一列（如
EmployeeID）作为第二排序项：ORDER BY Salary DESC, EmployeeID ASC - 避免用
NEWID()或GETDATE()做排序依据，它们每次执行结果都变 - 如果业务上真没唯一字段，可加
ORDER BY (SELECT NULL)强制稳定（但不推荐，语义不清）
参数化排序字段名时容易漏掉 COLLATE 或类型隐式转换
想让存储过程支持按不同列排序（如 @SortCol = 'Name' 或 'Salary'），常会拼接动态 SQL。这时最容易踩两个坑：
- 字符串字段排序受当前列的
collation影响，若列是VARCHAR且 collation 是SQL_Latin1_General_CP1_CI_AS，中文可能乱序；应显式加COLLATE Chinese_PRC_CI_AS（或更现代的Latin1_General_100_CI_AS_SC_UTF8） - 数值字段被当字符串拼进 SQL，比如
'ORDER BY ' + @SortCol，若 @SortCol = 'Salary'，但实际数据是VARCHAR类型存数字，就会触发字典序排序（"10" ORDER BY 后加CAST或确保原始列是数值类型 - 别用
sp_executesql传入排序字段名——参数只能是值，不能是列名或关键字；必须用字符串拼接，但要严格校验 @SortCol 是否在白名单内，防注入
真正决定结果顺序的，永远只有最外层 SELECT 的 ORDER BY，而且它必须能产生确定性排序。任何中间环节的排序声明、临时表的插入顺序、甚至物理存储顺序，都不构成保障。
