能，ORDER BY 后可跟多个排序条件，按从左到右优先级逐层排序，各字段可独立指定 ASC 或 DESC，NULL 处理和 collation 会影响结果。
ORDER BY 后面能跟多个排序条件吗
能，而且这是实现升序和降序混合排序的唯一标准做法。ORDER BY 允许用逗号分隔多个表达式，每个都可以独立指定 ASC 或 DESC，数据库会按从左到右的优先级逐层排序。
常见错误是以为只能统一升降序，或者误写成 ORDER BY col1 ASC, col2 DESC LIMIT 10 却发现结果不符合预期——往往是因为没意识到：前一列值相同时，才进入下一列的比较。
-
ORDER BY status ASC, created_at DESC：先按状态升序（比如 pending → processing → done），同状态内再按创建时间倒序（最新在前） - 如果某列含
NULL，注意不同数据库默认处理不同：PostgreSQL 和 SQL Server 把NULL当最大值（DESC时排最前），MySQL 默认当最小值；必要时显式加NULLS FIRST或NULLS LAST（仅 PostgreSQL、Oracle 等支持） - 字符串排序依赖 collation，比如大小写敏感与否会影响
'apple' 的结果，混合排序时容易被忽略
MySQL 8.0+ 和旧版在混合排序上有区别吗
语法上没区别，但 MySQL 8.0+ 支持 NULLS FIRST/LAST，而 5.7 及更早版本不支持，且 NULL 总是排在 ASC 结果最前、DESC 结果最后，无法调整。
例如想让 score 为 NULL 的记录排在非空记录之后（无论升序降序），在 MySQL 5.7 中只能靠表达式绕过：
ORDER BY (score IS NULL) ASC, score DESC
这个技巧利用布尔表达式返回 0 或 1，把 NULL 统一归到后面，再对真实值排序。注意括号不能省，否则运算符优先级会导致逻辑错乱。
WHERE 和 ORDER BY 混用时性能怎么保障
混合排序本身不慢，慢的是没走索引。数据库能否用索引加速 ORDER BY a ASC, b DESC，取决于索引定义是否匹配。
- 复合索引
INDEX(a, b)可以高效服务ORDER BY a ASC, b ASC，但对a ASC, b DESC—— 在 MySQL 8.0+ 和 PostgreSQL 中支持，MySQL 5.7 不支持“混合方向索引”，此时会退化为文件排序（Using filesort） - 若必须支持
a ASC, b DESC且用 MySQL 5.7，可建两个单列索引 + 覆盖索引优化，或改用生成列（generated column）+ 索引模拟反向值 - 用
EXPLAIN看执行计划里有没有Using filesort，有就说明排序没走索引，得调索引或查语句
ORDER BY 中能用表达式或别名吗
可以，但要注意兼容性。标准 SQL 允许在 ORDER BY 里直接写 SELECT 中定义的列别名，MySQL 和 PostgreSQL 支持，SQL Server 和 Oracle 要求别名不带引号且符合标识符规则；SQLite 支持但不推荐依赖别名，建议直接写表达式。
例如想按用户名首字母分组再按登录次数降序，有人会写：
SELECT SUBSTR(name, 1, 1) AS first_char, COUNT(*) AS cnt FROM users GROUP BY first_char ORDER BY first_char ASC, cnt DESC
这在多数引擎中可行，但更稳妥写法是重复表达式或用位置序号（如 ORDER BY 1 ASC, 2 DESC），不过后者可读性差，一旦 SELECT 列顺序变动就出错。
真正容易被忽略的是：排序表达式如果涉及函数（如 UPPER(name)）、类型转换（如 CAST(created_at AS DATE)）或子查询，几乎必然无法使用索引，即使写了对应索引也白搭——这时候得考虑提前物化或加函数索引（MySQL 8.0.13+、PostgreSQL 支持）。
