ORDER BY多字段排序优先级由书写顺序决定，从左到右逐级生效：先按首字段排序，值相同时再按次字段排序，以此类推。
ORDER BY 多字段排序的优先级由书写顺序决定
SQL 中没有“权重”“系数”或“配置项”来调整字段优先级，ORDER BY 后字段的**从左到右书写顺序就是实际生效的优先级顺序**。数据库先按第一个字段值分组排序；只有该字段值完全相等的行，才会进入第二个字段的比较；依此类推。
常见错误现象：ORDER BY status, created_at DESC 写成 ORDER BY created_at DESC, status，结果看似都含两个字段，但业务含义可能彻底反转——比如你想“先看审核通过的单子，再按时间倒序”，写反后就变成“先按最新时间排，再在同时间里看状态”，失去分类意义。
- 不要依赖列序号（如
ORDER BY 2, 1），SELECT 字段一改，排序逻辑就错位 - ASC 可省略，但 DESC 必须显式写出，否则默认升序，容易误判
- 混合方向时，各字段独立控制：
ORDER BY department ASC, salary DESC, name ASC
NULL 值位置不一致是跨库排序翻车主因
MySQL、PostgreSQL、SQL Server 对 NULL 在 ASC 下的默认位置不同：MySQL 把 NULL 排最前，PostgreSQL 排最后。同一段 SQL 换库执行，列表顺序可能颠倒，前端分页错乱。
可靠解法是用布尔表达式显式分离：ORDER BY is_promotion = 0, price ASC 这类写法在 MySQL/PostgreSQL/SQLite 全部有效。
-
register_time IS NULL返回0（非 NULL）或1（NULL），升序时0自然靠前 - 想把 NULL 放最后？用
ORDER BY register_time IS NULL, register_time ASC - 避免依赖 MySQL 8.0+ 的
NULLS LAST，低版本或兼容性场景会失效
组合索引必须严格匹配 ORDER BY 顺序才能跳过 filesort
ORDER BY 本身不慢，慢的是没索引支撑时触发的 filesort——数据量一过万，响应明显延迟。而能否走索引排序，关键看索引字段顺序是否与 ORDER BY **完全一致且无跳跃**。
例如查询：SELECT * FROM orders WHERE user_id = 123 ORDER BY status ASC, created_at DESC，理想索引是 (user_id, status, created_at)。注意三点：
- WHERE 条件字段（
user_id）必须放索引最左，否则无法利用 -
status和created_at的顺序、方向必须和 ORDER BY 完全一致；若索引是(status, created_at)但 WHERE 没用到status，该索引大概率被忽略 - 如果 ORDER BY 中有
DESC，MySQL 5.7 及更早版本要求索引也声明 DESC（8.0+ 支持混合方向索引）
低区分度字段前置会导致索引失效
别把 is_deleted TINYINT 或 status ENUM('draft','pending','done') 这类只有 2–5 个值的字段放在 ORDER BY 最前面。即使建了索引，95% 的记录在第一级排序中“撞在一起”，数据库仍要对海量行做第二级排序，索引形同虚设。
真实场景中，应把高区分度字段（如 created_at、id、email）前置，再补业务维度字段。
- 错误示范：
ORDER BY is_deleted, id→ 几乎全表参与id排序 - 正确思路：
ORDER BY created_at DESC, is_deleted→ 时间戳天然高区分，能快速切片 - 如果必须按状态优先，考虑加覆盖索引 + WHERE 过滤，减少参与排序的数据量
实际排序逻辑非常机械：只看字段值是否相等，相等才往下走。写的时候多问一句“这个字段值重复率高不高”“这个顺序是否符合用户一眼能理解的分层逻辑”，比调参数重要得多。
