ORDER BY多字段排序优先级由书写顺序决定，越靠前字段优先级越高；先按首字段排序，值相同时再按次字段排序，以此类推。
ORDER BY 多字段排序的优先级就是书写顺序
MySQL 里 ORDER BY 后面用逗号分隔多个字段，**越靠前的字段优先级越高**。数据库先按第一个字段排，相同值再按第二个字段排，以此类推。这不是“权重”或“系数”，而是严格的分层排序逻辑。
常见错误现象：ORDER BY status, created_at 却发现 created_at 像是主导了排序——其实是因为 status 大部分值相同（比如全是 'active'），根本没触发第二层比较。
- 使用场景：订单列表按状态（
status）分组显示，同状态内按时间倒序；用户按部门（dept_id）归类，部门内按职级（level）升序 - 参数差异：每个字段可独立指定
ASC或DESC，例如ORDER BY is_pinned DESC, updated_at DESC—— 置顶标记优先，再比更新时间 - 性能影响：只有当高优先级字段的值大量重复时，后续字段的索引才可能被用上；否则 MySQL 很可能只走第一个字段的索引，后面字段排序靠 filesort
DESC/ASC 必须显式写在每个字段后面
不能写成 ORDER BY a, b DESC 并期望 a 也按降序——这是错的。b DESC 只影响 b，a 默认是 ASC。MySQL 不会继承排序方向。
容易踩的坑：ORDER BY score DESC, name 会导致高分在前，但同分者按 name 升序（A-Z），如果本意是“同分者按姓名倒序”，就得写成 ORDER BY score DESC, name DESC。
- 示例对比：
SELECT * FROM users ORDER BY role, login_count DESC;→role升序（'admin' 在 'user' 前），同角色内login_count降序SELECT * FROM users ORDER BY role DESC, login_count DESC;→ 所有字段都降序 - 兼容性注意：SQLite、PostgreSQL 行为一致；但某些旧版 MySQL 在无显式声明时对中文或 NULL 的排序行为略有差异，建议始终写明
NULL 值在多字段排序中的实际位置
MySQL 默认把 NULL 当作最小值（ASC 时排最前，DESC 时排最后），这个规则对每个字段单独生效。多字段排序时，NULL 的“大小”只参与本字段比较，不影响后续字段的判断逻辑。
常见错误现象：想让未填日期的记录排最后，写了 ORDER BY deadline DESC，结果它们全堆在开头——因为 NULL 被当最小值，DESC 下反而成了最大“位置”。
- 解决办法：用
IS NULL控制顺序，例如ORDER BY (deadline IS NULL), deadline DESC，让非 NULL 先排，再按时间倒序 - 更安全的写法：
ORDER BY IFNULL(deadline, '9999-12-31') DESC，但要注意类型转换开销 - 注意：如果第一字段含大量
NULL，第二字段的排序效果会被掩盖——得先确认第一层是否真能有效区分数据
复合索引是否生效，取决于 ORDER BY 字段顺序和 WHERE 条件
即使写了 ORDER BY a, b, c，如果表上只有 (b, a, c) 索引，MySQL 通常不会用它来避免排序（filesort）。**索引字段顺序必须和 ORDER BY 前缀严格一致**，且中间不能跳过。
容易被忽略的地方：WHERE 条件会“截断”索引可用长度。比如有索引 (status, created_at, id)，查询 WHERE status = 'draft' ORDER BY created_at, id 能用上全部三列；但若 WHERE category = 'news'，那这个索引对排序完全无效。
- 验证方法：用
EXPLAIN看Extra列是否含Using filesort - 小技巧：如果经常按
(a DESC, b ASC)排序，建索引就得写成INDEX(a DESC, b ASC)（MySQL 8.0+ 支持，5.7 及以前一律按 ASC 存，DESC 仅语义） - 别依赖“覆盖索引”自动优化多字段排序——它只减少回表，不消除排序步骤
事情说清了就结束
