ORDER BY 多字段排序语法为按优先级从左到右列出字段，用逗号分隔，各字段可独立指定ASC或DESC（未声明默认ASC）；数据库先按首字段排序，相同时再按次字段排序，以此类推。
ORDER BY 多字段排序的语法结构怎么写
直接在 ORDER BY 后面按优先级从左到右列出字段，用逗号分隔。数据库会先按第一个字段排序，相同时再按第二个字段排，以此类推。
常见错误是误以为字段间需要加 AND 或括号，其实不需要——ORDER BY name, age, id 是合法且标准的写法；ORDER BY (name, age) 在大多数数据库里会报错（PostgreSQL 除外，但语义不同）。
- 每个字段可单独指定方向：
ORDER BY status DESC, created_at ASC, id DESC - 未声明方向时默认为
ASC，不是空值优先，也不是随机 - 字段可以是列名、别名（需在 SELECT 中定义）、表达式（如
LENGTH(title)），但不能是未出现在 SELECT 中的位置索引（如ORDER BY 1,2虽然某些方言支持，但可读性差且易出错）
NULL 值在多字段排序中怎么处理
不同数据库对 NULL 的默认排序行为不一致：MySQL 和 PostgreSQL 默认把 NULL 当作“最大值”（即 ASC 时排最后），SQL Server 默认当“最小值”（ASC 时排最前）。一旦涉及多字段，这个差异会放大。
比如 ORDER BY category ASC, price ASC，若某行 category 非空但 price 为 NULL，它可能被挤到中间或末尾，取决于 price 字段的 NULL 排序策略。
- 显式控制
NULL位置更可靠：ORDER BY category ASC, price ASC NULLS LAST（PostgreSQL/Oracle 支持） - MySQL 不支持
NULLS FIRST/LAST，得用IS NULL表达式模拟：ORDER BY category ASC, (price IS NULL) ASC, price ASC - SQLite 用
IS运算符：ORDER BY category ASC, price IS NULL, price ASC
为什么加了索引还是慢：复合排序与索引匹配问题
即使你为 ORDER BY a, b, c 创建了联合索引，也不代表一定能走索引排序。关键看查询条件是否“覆盖前缀”。
例如有索引 INDEX idx_ab (a, b, c)：
-
WHERE a = 1 ORDER BY b, c：能用上索引做排序（a等值过滤后，剩余字段天然有序） -
WHERE b = 2 ORDER BY a, c：无法利用该索引排序，因为没过滤a，b不是索引最左列 -
WHERE a > 1 ORDER BY a, b：可以，范围查询后仍保持a,b的局部有序 -
ORDER BY a DESC, b ASC：MySQL 8.0+ 支持混合方向索引，但老版本只支持全ASC或全DESC才能用于排序
ORDER BY 后字段顺序影响结果稳定性吗
影响，而且非常实际。只要存在任意两行在所有排序字段上完全相同，数据库返回顺序就不可靠——即使加了索引，也可能因并发写入、执行计划变化或存储页重组导致每次查询结果顺序微调。
这在分页场景下尤其危险：OFFSET 100 LIMIT 10 可能跳过或重复记录。
- 解决办法是补一个唯一字段兜底：
ORDER BY status, created_at, id（假设id主键唯一） - 避免仅用非唯一字段排序后直接分页，尤其是带
LIMIT/OFFSET的 API 分页 - 如果业务真允许“相同状态并列”，也要意识到前端展示时可能每次刷新顺序不同，这不是 bug，是 SQL 标准允许的行为
多字段排序看着简单，但 NULL 处理、索引利用、结果稳定性这三点最容易在线上突然冒出来。尤其是第三点，等分页错乱了再补 id 就晚了。
