MySQL的ORDER BY多字段排序严格从左到右逐级生效：先按首字段排序，值相等时再按次字段排序，以此类推；各字段方向需显式声明，NULL默认最小，索引利用要求字段顺序和方向与索引定义完全一致。
ORDER BY 多字段排序的执行顺序是啥
MySQL 的 ORDER BY 多字段排序不是“并行比较”，而是严格从左到右逐级生效：先按第一个字段分组排序，只有值完全相等的行，才会进入第二个字段的比较；以此类推。这就像图书馆先按分类号排，同类书再按作者姓氏排，同作者才看出版年份。
常见错误是以为 ORDER BY status, created_at DESC 表示两个字段都降序——其实 status 是默认 ASC，只有 created_at 是 DESC。
- 写法必须用逗号分隔：
ORDER BY a ASC, b DESC, c ASC - 不能省略方向依赖默认值，尤其当后续修改列顺序或语义时容易出错
- 错误写法如
ORDER BY a DESC b DESC（缺逗号）会直接报语法错误 - 用数字位置（如
ORDER BY 1, 3 DESC）虽合法，但 SELECT 列一变，排序就失效，且不可维护
NULL 值在多字段排序中怎么处理
MySQL 默认把 NULL 当作最小值：升序时排最前，降序时排最后，且该规则对每个字段独立生效。
比如 ORDER BY category_id ASC, sort_order DESC 中，所有 category_id IS NULL 的行会先被聚在最前面，这部分内部再按 sort_order 降序排；而 category_id 非空但 sort_order IS NULL 的行，则会在各自 category_id 组内排最后（因为 DESC 下 NULL 最小 → 排最后）。
- 想让
NULL统一排最后（哪怕升序），得显式控制：ORDER BY (category_id IS NULL) ASC, category_id ASC - MySQL 8.0+ 支持更简洁写法：
ORDER BY category_id ASC NULLS LAST - 注意：不同 MySQL 版本对
NULLS LAST支持不一，5.7 及更早版本不识别，会报错
为什么加了索引，ORDER BY 还很慢
多字段排序能否走索引，取决于查询的字段顺序、方向是否与索引定义「完全一致」。哪怕只差一个方向，也可能触发 filesort。
假设有联合索引 INDEX idx_status_created (status, created_at)：
-
ORDER BY status ASC, created_at ASC→ 可走索引 -
ORDER BY status DESC, created_at DESC→ MySQL 5.7+ 支持反向扫描，可走索引（有轻微开销） -
ORDER BY status ASC, created_at DESC→ 方向不一致，无法利用该索引排序，触发filesort -
ORDER BY created_at, status→ 字段顺序不匹配，同样无法利用
用 EXPLAIN 查看 Extra 列是否含 Using filesort 是最快判断方式。一旦掉出索引覆盖，数据量稍大（比如几万行以上），filesort 就会明显拖慢响应。
ORDER BY 后能用别名或计算字段吗
可以，而且推荐用别名——更清晰、更安全。
比如按年薪排序：SELECT employee_id, salary * 12 AS annsal FROM employees ORDER BY annsal; 比直接写 ORDER BY salary * 12 更易读，也避免重复计算。
- 别名必须在
SELECT中定义后才能用于ORDER BY - 计算字段也可直接用，但要注意表达式一致性（如
ORDER BY UPPER(name)和SELECT UPPER(name)要保持一致） - 子查询、函数、甚至 CASE 表达式都支持，但复杂表达式可能影响索引使用，需结合
EXPLAIN验证
真正容易被忽略的是：排序逻辑和业务语义是否真正对齐——比如「先按状态再按时间」看似合理，但如果状态字段大量重复（如 95% 都是 'active'），那第二字段实际承担了主排序职责，此时它有没有索引、是否允许 NULL，就比第一字段更重要。
