order by 多列排序中，每列方向需显式指定且仅作用于该列，顺序决定优先级；null处理和索引支持因数据库而异，需结合执行计划优化。
ORDER BY 多列混合排序的语法结构
SQL 的 ORDER BY 支持为每一列单独指定排序方向，用 ASC（升序，可省略）或 DESC（降序）明确声明。关键在于：方向修饰符只作用于紧邻其前的列名，不传递、不继承。
- 每个列后必须显式写
ASC或DESC，否则默认为ASC - 逗号分隔多个排序项，顺序即优先级：先按第一列排，相同时再按第二列，依此类推
- 错误写法：
ORDER BY name, age DESC—— 这里只有age是降序，name是默认升序，但容易误读为“全部降序”
示例：
SELECT * FROM users ORDER BY status ASC, created_at DESC, id ASC;表示：先按
status 升序；相同 status 的记录，再按 created_at 降序（最新在前）；仍相同时，按 id 升序兜底。
常见错误：DESC 被误认为全局生效
很多初学者会写成类似 ORDER BY a, b DESC，以为 b DESC 会让整个排序都倒过来，实际不是。
- 真实效果：
a升序 +b降序（仅b） - 更隐蔽的坑：
ORDER BY a DESC, b，这里a降序，b升序（因未写ASC，但很多人以为“前面写了 DESC，后面也跟着 DESC”）
容易出错的场景：
- 分页查询中依赖稳定排序，但漏写某列方向，导致同页数据顺序漂移
- 和
GROUP BY混用时，ORDER BY列未覆盖所有非聚合字段，触发 SQL 标准报错（如 PostgreSQL） - 在 MySQL 5.7+ 严格模式下，若
SELECT中有非排序列且无聚合，可能报错
不同数据库对 NULL 的处理影响混合排序结果
ORDER BY 中，NULL 值的默认位置因数据库而异，直接影响混合排序的可视结果：
- PostgreSQL / SQL Server：默认
NULLS FIRST（ASC时NULL排最前，DESC时反而也排最前） - MySQL：
NULL总是排在最前（无论ASC或DESC） - SQLite：行为类似 MySQL
如果业务要求 NULL 统一排最后，需显式加 NULLS LAST（PostgreSQL/Oracle 支持），MySQL 不支持该语法，得用 IS NULL 表达式模拟：
ORDER BY (email IS NULL) ASC, email ASC
性能提示：混合排序是否走索引？
复合索引能否被 ORDER BY a ASC, b DESC 利用，取决于数据库版本和索引定义：
- MySQL 8.0+ 支持为单个索引中不同列指定方向（如
INDEX idx(a ASC, b DESC)），此时能命中 - MySQL 5.7 及更早：只支持全 ASC 或全 DESC 的复合索引匹配，
a ASC, b DESC无法使用(a,b)索引，会回表或文件排序 - PostgreSQL 对混合方向索引支持较好，但需建索引时显式声明：
CREATE INDEX idx ON t (a ASC, b DESC);
检查是否走索引的方法：
- MySQL：用
EXPLAIN看Extra是否含Using filesort - PostgreSQL：用
EXPLAIN ANALYZE看是否出现Sort节点
混合方向排序本身不慢，慢的是没索引支撑时的临时排序。别只盯着写法，先看执行计划。
