order by 多列混合排序按从左到右顺序逐级生效，每列须显式指定asc或desc（默认asc），逗号分隔，如order by status desc, created_at asc；后续字段仅在前序字段值相同时起作用。
ORDER BY 多列混合排序的语法结构
SQL 的 ORDER BY 支持对多个字段依次排序，每列可独立指定升序（ASC）或降序（DESC），不写时默认为 ASC。关键点在于：排序是从左到右逐级生效的——先按第一列排，相同值再按第二列排，依此类推。
- 多列之间用英文逗号分隔，每列后紧跟
ASC或DESC - 混合写法合法且常见，比如
ORDER BY status DESC, created_at ASC, id DESC - 所有主流数据库（PostgreSQL、MySQL 8.0+、SQL Server、SQLite）都支持该语法；MySQL 5.7 对
DESC修饰符的支持在某些旧版本中存在解析限制，建议升级或显式写全
为什么「先排 A 再排 B」不等于「A 和 B 同时排序」
这是最容易误解的地方：ORDER BY a DESC, b ASC 不是对 a 和 b 分别做全局升降序后合并结果，而是构建一个字典序优先级队列：
- 先将所有行按
a降序排列（最大值在最前） - 在每一组
a值相同的记录内部，再按b升序排列 - 如果
a完全不重复，那b的排序效果根本不会体现
常见错误现象：
- 写了
ORDER BY price DESC, name ASC，但发现名字看起来“乱序”——其实是 price 都不同，name 根本没机会参与排序 - 误以为加了多列就能“平衡排序”，实际仍是严格层级关系
真实场景下的典型用法与陷阱
电商订单列表常用：ORDER BY is_paid DESC, updated_at DESC
→ 已支付订单在前，同为已支付的按最新更新时间排；未支付的在后，内部也按更新时间倒序
容易踩的坑：
-
NULL值排序行为因数据库而异：PostgreSQL 中NULLS FIRST/LAST可控，MySQL 和 SQL Server 默认把NULL当最小值（ASC时在最前），可能打乱预期 - 字符串字段用
ASC时，大小写敏感性依赖 collation，可能导致 'Z' 排在 'a' 前面（如 utf8mb4_bin） - 在带
LIMIT的分页查询中，若排序字段存在大量重复值（比如多个订单is_paid = 1且updated_at相同），不同页可能漏数据或重复，应补上唯一字段如id保序稳定
如何验证混合排序是否生效
最直接的办法是查出原始数据片段，人工对照排序逻辑：
SELECT id, status, score FROM exams ORDER BY status DESC, score ASC LIMIT 10;
观察输出：
- status 值是否从高到低（如 'A', 'B', 'C'）
- 当 status 相同时（比如连续几行都是 'B'），score 是否从小到大排列
如果不符合，优先检查：
- 是否漏写了
DESC/ASC，导致某列用了默认ASC却预期是降序 - 字段名拼写错误或引用了错误表别名，使排序实际作用于常量或 NULL
- 应用层代码覆盖了 SQL 的
ORDER BY（比如 ORM 自动追加了其他排序）
混合排序本身不难，难的是意识到「排序键的顺序即优先级顺序」，以及在重复值密集时，后续字段是否真能起到区分作用——这往往比语法更影响结果。
