mysql多字段排序语法为order by field1 [asc|desc], field2 [asc|desc]，字段用逗号分隔，各字段方向独立指定，默认asc；排序严格按从左到右优先级嵌套执行，仅当左侧字段值相等时才比较右侧字段。
ORDER BY 多字段排序的语法结构怎么写
MySQL 的 ORDER BY 支持多个字段连续排序，核心是用逗号分隔字段，并为每个字段单独指定 ASC 或 DESC——不写时默认为 ASC，且只作用于紧邻它的前一个字段，不会“继承”到后续字段。
常见错误是以为写成 ORDER BY name, age DESC 表示两个字段都降序，其实只有 age 降序，name 是升序。正确写法必须显式声明：ORDER BY name DESC, age DESC。
实操建议：
- 始终为每个字段明确写出
ASC或DESC，避免隐式行为引发误解 - 字段顺序决定优先级：先按第一个字段排，相同时再按第二个字段排，以此类推
- 混合方向完全合法，比如
ORDER BY status ASC, created_at DESC（先按状态升序，同状态内按时间倒序）
NULL 值在多字段排序中怎么处理
MySQL 默认把 NULL 当作最小值（ASC 时排最前，DESC 时排最后），但这个规则对每个字段独立生效，且无法跨字段统一控制。
比如 ORDER BY a ASC, b DESC 中，如果某行 a 是 NULL，它会排在所有非空 a 前面；而这些 a 为 NULL 的记录之间，再按 b 降序排——此时 b 为 NULL 的又会排在这些组的末尾。
容易踩的坑：
- 业务上希望
NULL排最后？得用IS NULL手动挪位置，例如：ORDER BY (a IS NULL) ASC, a ASC, (b IS NULL) ASC, b DESC -
COALESCE()虽能替换NULL，但可能改变原始数据语义，慎用于数值或日期字段 - 索引能否覆盖含
NULL的多字段排序？取决于索引定义是否包含对应字段及方向，NULL不影响索引可用性，但会影响排序效率
多字段排序和索引匹配的关键条件
不是所有 ORDER BY a, b 都能走索引。MySQL 只有在满足“最左前缀 + 方向一致”时才可能利用索引避免文件排序（Using filesort）。
假设你建了联合索引 INDEX idx_ab (a, b)：
-
ORDER BY a, b✅ 可走索引 -
ORDER BY a DESC, b DESC✅ 可走索引（8.0+ 支持反向扫描） -
ORDER BY a ASC, b DESC❌ 通常触发Using filesort（除非优化器选择松散索引扫描等特殊情况） -
ORDER BY b❌ 索引失效，因为跳过了最左列a
查执行计划时重点看 Extra 列是否有 Using filesort，有就说明排序没走索引，大数据量下性能风险明显。
ORDER BY 和 LIMIT 一起用时的陷阱
多字段排序 + LIMIT 组合看似简单，但极易因数据重复导致结果不稳定。
比如用户表按 score DESC, id ASC 取前 10 条，如果第 10 名和第 11 名 score 相同、id 不同，两次查询可能返回不同记录——因为 MySQL 不保证相同排序键下的物理顺序稳定，除非你把足够多的字段加进 ORDER BY 形成唯一排序键。
实操建议：
- 线上分页务必让
ORDER BY的字段组合能唯一确定每一行，常用做法是末尾加上主键，如ORDER BY score DESC, id ASC - 避免仅靠业务字段（如
created_at）排序后分页，微秒级时间重复很常见 -
LIMIT在多字段排序中不改变排序逻辑，但它放大了排序不确定性的后果
真正麻烦的从来不是语法写不对，而是排序键不够唯一、索引没对上、或者 NULL 和 LIMIT 碰在一起时，结果看起来“偶尔错”。
