MySQL多字段排序按从左到右优先级嵌套执行：先按首字段排序，值相等时才用次字段，依此类推；语法为ORDER BY field1 [ASC|DESC], field2 [ASC|DESC]，各字段方向可独立指定，默认ASC。
MySQL 中多字段排序不是“多个字段一起排”，而是严格按从左到右的优先级嵌套判定——只有左侧字段值完全相等的行，才会进入右侧字段的比较。这点不理解，写出来的 ORDER BY 很可能逻辑错位，但 SQL 还能正常执行，查不出错，只在业务上悄悄出问题。
ORDER BY 多字段语法怎么写才对
必须用逗号分隔字段，每个字段可独立指定 ASC 或 DESC，不写默认 ASC：
SELECT * FROM orders ORDER BY status ASC, created_at DESC, id DESC;
常见错误写法包括：
- 误以为
ORDER BY a, b DESC表示 “a 和 b 都降序”——其实 a 是升序，b 才是降序 - 写成
ORDER BY a DESC b DESC（漏逗号），直接报语法错误 - 用数字位置如
ORDER BY 1, 3 DESC——一旦 SELECT 列顺序调整，排序就失效，且不可读
NULL 值在多字段排序中怎么排
MySQL 默认把 NULL 当作最小值：升序时排最前，降序时排最后。这个行为会逐字段生效，且影响排序稳定性。
比如 ORDER BY category_id ASC, sort_order ASC 中，只要 category_id 是 NULL，整行就排在最前面，不管 sort_order 是多少；同理，若 category_id 非空但 sort_order 是 NULL，那它会在该 category_id 组内排最前。
想让 NULL 统一排最后？得显式控制：
ORDER BY category_id IS NULL, category_id ASC, sort_order IS NULL, sort_order ASC
更简洁的写法（MySQL 8.0+）：
ORDER BY category_id ASC NULLS LAST, sort_order ASC NULLS LAST
为什么加了索引，ORDER BY 还很慢
多字段排序能否走索引，取决于索引定义是否「方向匹配 + 顺序一致」。
例如查询：
SELECT * FROM users WHERE dept = 'tech' ORDER BY salary DESC, hire_date ASC;
理想索引应为：
(dept, salary DESC, hire_date ASC)
但注意：
- MySQL 5.7 不支持混合方向索引，
salary DESC, hire_date ASC实际会退化为全扫描或 filesort - MySQL 8.0+ 支持，但必须显式建为
INDEX(dept, salary DESC, hire_date ASC)，不能只建(dept, salary, hire_date) - 如果 WHERE 条件用了
dept IN ('tech', 'design')，即使有索引，ORDER BY也大概率无法利用，因为范围条件后索引失效
和 LIMIT 搭配时最容易忽略的坑
带 LIMIT 却没写 ORDER BY，结果顺序不确定；写了 ORDER BY 但字段组合不能唯一确定每行顺序，分页时就会跳行或重复。
比如分页取第 21–30 条：
SELECT * FROM products ORDER BY category_id, price LIMIT 20, 10;
如果多个商品 category_id 和 price 完全相同，MySQL 可能每次返回不同子集。真正稳定的写法是补上唯一字段：
ORDER BY category_id, price, id
关键点在于：多字段排序的「最右字段」最好是有索引的主键或时间戳，否则稳定性和性能都难保障。
