MySQL中ORDER BY字段顺序即排序优先级顺序：先按首字段排序，相同时再按次字段排序，依此类推；各字段ASC/DESC需单独声明，NULL默认升序排最前、降序排最后。
MySQL 的 ORDER BY 子句中字段的书写顺序，就是实际生效的排序优先级顺序——先按第一个字段排，相同值的再按第二个字段排，依此类推。这不是“建议”，而是 SQL 标准行为。
ORDER BY 字段顺序决定排序层级
比如 ORDER BY status DESC, created_at ASC, id DESC 表示：
- 所有行先按
status降序排列（如 'active' > 'pending' > 'closed'） - 当
status相同时，这部分子集再按created_at升序排列 - 若
status和created_at都相同，最后才用id降序兜底
这个层级不能靠加括号或调整 WHERE 条件改变，只取决于 ORDER BY 后字段的出现次序。
混用 ASC/DESC 容易漏掉默认行为
ASC 是默认排序方向，但一旦显式写了 DESC，就容易误以为前面的字段也自动是 DESC。实际上每个字段的方向必须单独声明：
- ❌ 错误写法：
ORDER BY a, b DESC→a是ASC，b是DESC，但很多人以为a也是降序 - ✅ 明确写法：
ORDER BY a DESC, b DESC或ORDER BY a ASC, b DESC
尤其在调试结果不符合预期时，先检查每个字段是否都带了明确的 ASC/DESC。
自定义顺序字段（如 FIELD()）要放在层级靠前位置
如果要用 FIELD(status, 'draft','review','published') 实现业务状态的非字典序排列，它必须出现在 ORDER BY 列表的合理位置：
- 想让 'published' 永远排最前？把它放在第一个 ——
ORDER BY FIELD(status, 'published','review','draft'), updated_at DESC - 如果放在第二位，那只有
status值相同时才会触发该规则，起不到主控作用 -
FIELD()返回整数，所以后续字段仍可接ASC/DESC，但别对FIELD()结果再套函数（如ABS(FIELD(...))），会丢失索引能力
NULL 值排序行为常被忽略
MySQL 中 NULL 在升序时排最前、降序时排最后，且这个行为无法通过 ASC/DESC 反转。如果字段可能为 NULL，又需要统一置顶或置底：
- 用
IS NULL布尔表达式参与排序：ORDER BY (priority IS NULL) ASC, priority DESC让非空priority优先且降序，NULL排最后 - 避免依赖数据库默认的
NULL位置，特别是跨 MySQL 版本或迁移到 PostgreSQL 时，NULLS FIRST/LAST语法不兼容
多字段排序真正难的不是写法，而是想清楚哪个字段该承担“分组锚点”角色、哪个字段只是“组内微调”。顺序写错，结果可能完全不可逆，查半天才发现是 ORDER BY 第一个字段选错了。
