SQL排序需显式用ORDER BY指定方向与逻辑，不可依赖默认；NULL处理、中文排序、多字段优先级、表达式排序及关联查询陷阱均需精准控制。
SQL排序规则不是靠“设置”一劳永逸的配置项，而是通过 ORDER BY 子句 + 显式指定排序方向与字段逻辑 来动态控制的。关键不在“设”，而在“写得准、想得清”。下面用真实场景拆解常见误区和进阶用法。
基础排序：别只依赖默认ASC，方向必须明确
很多人写 ORDER BY price 就以为是“从小到大”，其实它等价于 ORDER BY price ASC，但一旦涉及 NULL、字符串或本地化数据，隐式行为容易翻车。
- NULL 默认排在最前（PostgreSQL）或最后（MySQL 8.0+），不统一；显式用
NULLS FIRST或NULLS LAST（支持该语法的数据库如 PostgreSQL、Oracle）更可靠 - 中文字段排序常乱序？因为默认按字节比较，不是按拼音。例如：
ORDER BY name COLLATE Chinese_PRC_CI_AS（SQL Server）或ORDER BY name COLLATE utf8mb4_unicode_ci（MySQL）才能正确按拼音排 - 时间字段别只写
ORDER BY create_time，加上DESC才能拿到最新记录在前——这是分页、消息流等场景的刚需
多字段组合排序：顺序即优先级，括号不解决逻辑问题
写 ORDER BY status, updated_at DESC 并不等于“先按状态升序，再按更新时间降序”。真实执行逻辑是：先按 status 升序分组，每组内再按 updated_at 降序。很多同学误以为加括号能改变优先级，但 SQL 标准中 ORDER BY (a,b) DESC 是非法写法。
- 正确写法只有：
ORDER BY status ASC, updated_at DESC（ASC 可省略，但建议写全，提升可读性） - 典型场景：订单列表 → 先按「是否已支付」分层（未支付在前），同状态下再按「下单时间倒序」
ORDER BY paid_status ASC, order_time DESC - 注意字段类型混合风险：比如
ORDER BY is_top DESC, sort_weight DESC, id ASC，确保 sort_weight 是数值型，否则字符串“10”会排在“2”前面
表达式与函数排序：让排序真正“动起来”
排序字段不必是物理列，可以是计算结果、条件判断甚至 JSON 提取值——这才是处理复杂业务逻辑的核心能力。
- 按“剩余有效期”倒序，但过期的排最后：
ORDER BY (CASE WHEN expire_date >= NOW() THEN 0 ELSE 1 END), expire_date DESC - MySQL 中按 JSON 字段里的 price 排序：
ORDER BY JSON_UNQUOTE(JSON_EXTRACT(extra_info, '$.price')) + 0 DESC - PostgreSQL 按数组长度排序（比如标签数）：
ORDER BY array_length(tags, 1) DESC - 避免在 ORDER BY 里写复杂子查询（性能杀手），优先考虑提前计算好排序权重存为生成列（Generated Column）或在应用层预处理
关联查询中的排序陷阱：别在子查询里随便 ORDER BY
很多人想“先取最新5条评论”，就写：SELECT * FROM (SELECT * FROM comment ORDER BY ctime DESC LIMIT 5) t JOIN post ON t.post_id = post.id。看起来对，但实际隐患很大：
- 如果外层还有
ORDER BY，子查询的ORDER BY可能被优化器忽略（尤其没加 LIMIT 时） - 正确做法：子查询排序 + LIMIT 仅用于“取TopN”，且必须配合外层确定性排序（如按主键补全）防止结果不稳定
SELECT * FROM (SELECT * FROM comment ORDER BY ctime DESC, id DESC LIMIT 5) t JOIN post USING(post_id) - 更健壮方案：用窗口函数替代，比如
ROW_NUMBER() OVER (PARTITION BY post_id ORDER BY ctime DESC, id DESC)，再过滤 rn ≤ 5，逻辑清晰且可复用
基本上就这些。排序不是末端美化，而是查询逻辑的终点表达。写好 ORDER BY，等于把业务规则翻译成了数据库能懂的语言。不复杂，但容易忽略细节。
