多字段排序优先级从左到右依次生效，先按首字段排序，值相同时再按次字段排序；各字段升降序需显式指定，默认asc。
ORDER BY 后多个字段怎么写，优先级怎么定
多列排序的核心规则是：从左到右依次生效，左边字段相同时才用右边字段比较。比如 ORDER BY status, created_at DESC，先按 status 升序排，相同 status 的记录再按 created_at 降序排。
常见错误是以为所有字段默认同向排序——其实每个字段都要显式指定 ASC 或 DESC，没写的默认是 ASC。
-
ORDER BY a, b等价于ORDER BY a ASC, b ASC -
ORDER BY a DESC, b表示 a 降序、b 升序（不是“整体降序”） - 字段顺序不能颠倒：想先按时间再按状态，就得写
ORDER BY created_at, status，反过来逻辑就变了
NULL 值在多列排序里怎么处理
不同数据库对 NULL 的默认排序位置不一致：MySQL 和 PostgreSQL 默认把 NULL 排在最前（ASC 时），SQL Server 默认排最后。这会导致跨库迁移时排序结果突变。
稳妥做法是显式控制 NULL 位置：
- MySQL/PostgreSQL：用
IS NULL或IS NOT NULL配合ORDER BY，例如ORDER BY (status IS NULL), status, created_at DESC - PostgreSQL 还支持
NULLS FIRST/NULLS LAST（标准 SQL），如ORDER BY status NULLS LAST, created_at DESC - SQL Server 可用
CASE WHEN status IS NULL THEN 1 ELSE 0 END临时垫高/压低
带函数或表达式的多列排序要注意什么
可以在 ORDER BY 里直接写函数或计算表达式，比如 ORDER BY UPPER(name), LENGTH(description) DESC，但要注意两点：
- 性能风险：如果字段没函数索引，
UPPER(name)会强制全表扫描；MySQL 8.0+ 支持函数索引，PostgreSQL 支持表达式索引，记得提前建 - 可读性陷阱：别写
ORDER BY 1, 2这种位置序号——虽然语法允许，但一旦 SELECT 列顺序或数量变化，排序就错乱，且别人看不懂 - 别在
ORDER BY里引用未出现在SELECT中的非分组字段（尤其在GROUP BY查询中），MySQL 5.7+ 严格模式会报错
ORDER BY 多列时性能掉得厉害，怎么查原因
执行计划里看到 Using filesort（MySQL）或 Sort 节点（PostgreSQL）不一定是坏事，但若耗时突增，先确认是否命中索引：
- 复合索引必须「最左匹配」：想加速
ORDER BY a, b DESC，索引得是(a, b)或(a, b DESC)（PostgreSQL 支持方向定义，MySQL 8.0+ 也支持） - WHERE 条件字段和 ORDER BY 字段要一起考虑：比如
WHERE category = 'book' ORDER BY price, title，最优索引是(category, price, title) - 如果排序字段有混合方向（如
a ASC, b DESC），旧版 MySQL 不支持混合方向索引，会退化为文件排序；升级或改用单向组合
真正容易被忽略的是：ORDER BY 的字段类型和 WHERE 中的不一致，比如 WHERE 用字符串匹配 id = '123'（触发隐式转换），导致索引失效，连带让后续排序也慢下来。
