多字段排序按order by从左到右逐级生效，顺序即优先级；需显式指定各字段asc/desc；null处理需适配数据库特性；索引须与排序字段顺序及方向一致才能生效。
ORDER BY 后多个字段怎么写才不乱序
多字段排序不是简单用逗号拼接就完事——顺序决定优先级，ORDER BY 从左到右逐级生效。比如 ORDER BY status, created_at，先按 status 分组排，每组内再按 created_at 排；反过来写就是完全不同的结果。
常见错误是把高优先级字段放后面，导致看起来“没生效”。比如想先看最新数据、再按状态细分，却写了 ORDER BY status, created_at DESC，结果所有 status = 'pending' 的记录挤在前面，根本看不到时间维度的分布。
- 字段顺序即排序层级：左边最重，右边是“同级内的次级规则”
- 同一语句中，不能对同一个字段既指定
ASC又指定DESC（语法报错） - MySQL 8.0+ 和 PostgreSQL 支持表达式排序，如
ORDER BY LENGTH(name), name，但 SQLite 不支持函数直接进ORDER BY（需用子查询或别名）
ASC 和 DESC 能不能混着用？怎么指定才不报错
能混，而且必须显式指定——每个字段的排序方向默认都是 ASC，不写就是升序。一旦某个字段要降序，就得紧挨着它写 DESC，不能靠前或靠后“统一声明”。
错误写法：ORDER BY name, age DESC 看似只给 age 加了 DESC，其实 name 是默认 ASC，没问题；但如果你本意是两个都降序，漏写第一个的 DESC，就会出意料之外的结果。
- 正确写法：
ORDER BY name DESC, age ASC或ORDER BY name DESC, age（后者age默认ASC） - PostgreSQL 允许
NULLS FIRST/NULLS LAST，MySQL 不支持，遇到空值时行为可能不一致（MySQL 把NULL当最小值，ASC时排最前） - 某些 ORM（如 Django ORM）生成 SQL 时会自动补全
ASC，但原生 SQL 中不写就是ASC，别误以为“不写=忽略方向”
带 NULL 值的字段排序总跑最前/最后，怎么控住
NULL 在排序中不是“空”，而是“未知”，SQL 标准规定它既不大于也不小于任何值，所以数据库自己定规则：MySQL 把 NULL 当最小，ASC 时排头，DESC 时排尾；PostgreSQL 默认相反，但可干预。
想让 NULL 固定排最后（比如“无截止日期”的任务放底部），不能靠猜，得明确写条件：
- MySQL 5.7+：用
IS NULL布尔表达式辅助，如ORDER BY (deadline IS NULL), deadline ASC—— 布尔值0/1控制分组，再排真实值 - PostgreSQL：直接加
NULLS LAST，如ORDER BY deadline ASC NULLS LAST - 通用写法（兼容性最强）：用
CASE，如ORDER BY CASE WHEN deadline IS NULL THEN 1 ELSE 0 END, deadline ASC
ORDER BY 多字段影响性能吗？什么时候要加索引
影响很大，尤其是没索引时。数据库只能全表扫描 + 内存排序（Using filesort），数据量一过万，响应明显变慢。
索引不是随便建：只有当 ORDER BY 字段顺序和索引字段顺序一致、且方向（ASC/DESC）也匹配时，才能跳过排序步骤。比如有索引 INDEX(status, created_at)，那 ORDER BY status ASC, created_at DESC 就无法利用（方向不一致）；而 ORDER BY status ASC, created_at ASC 或 status DESC, created_at DESC 都可以。
- 复合索引最左前缀原则依然适用：
ORDER BY created_at, status无法用(status, created_at)索引 - 如果查询还带
WHERE，索引要兼顾过滤和排序，例如WHERE status = 'done' ORDER BY created_at，适合建(status, created_at) - MySQL 8.0 开始支持降序索引定义，如
INDEX(status, created_at DESC)，但老版本只能靠CASE或冗余字段绕过
多字段排序真正麻烦的不是语法，而是你得同时盯住三件事：字段逻辑优先级、NULL 的实际表现、索引能不能吃上——少看一个，查出来就是错的或者慢的。
