ORDER BY 字段名默认升序（ASC可省略但建议显式写出），必须位于WHERE和GROUP BY之后；升序对NULL的处理因数据库而异，字符型、日期型字段严格按编码规则排序。
ORDER BY 字段名后面不加 DESC 就是升序，而且 ASC 可以省略——但建议显式写上，避免后续逻辑被误读。
升序是默认行为，但别依赖它
很多新人看到 SELECT * FROM users ORDER BY age; 返回结果是从小到大，就以为“没写 ASC 也行”。确实行，但这是数据库的默认约定，不是语法强制。显式写 ASC 能让意图更清晰，尤其在多人协作或后期维护时，别人一眼就知道你就是要升序，而不是忘了写方向。
ORDER BY 必须放在 WHERE 和 GROUP BY 之后
SQL 执行顺序决定了排序必须在过滤和分组完成之后进行。如果把 ORDER BY 放在 WHERE 前面，会直接报错 ERROR: syntax error at or near "ORDER"。
正确顺序示例：
SELECT id, name, score FROM student_score WHERE score IS NOT NULL ORDER BY score ASC;
常见错误包括：
- 把
ORDER BY写在WHERE前面 - 在子查询里漏掉外层
ORDER BY（子查询本身不保证顺序） - 对含
NULL的字段升序时，发现NULL排最前——这是多数数据库（如 PostgreSQL）的默认行为，MySQL 则可能排最后，不可跨库假设
字符型、日期型字段升序也按字面规则走
升序不是“看起来合理”，而是严格按底层排序规则执行：
-
VARCHAR字段（如username）按字符集编码升序，比如 ASCII 下'Apple''apple'（大写字母码值更小） -
DATETIME字段（如create_time）从最早时间排到最晚，'2023-01-01'在'2024-01-01'前面 - 数值型字段（如
amount）按数值大小，不是字符串长度：9在10前面
别用列位置编号代替字段名
虽然 ORDER BY 3 ASC 看起来省事（表示按 SELECT 第三个字段升序），但它极脆弱：
- 一旦 SELECT 列顺序调整（比如把
score从第 3 位挪到第 4 位），排序就错乱了 - 字段别名无法用位置引用（
SELECT (a+b) AS total ORDER BY 1 ASC是合法的，但可读性差） - 团队代码审查时容易被质疑，属于“能跑但不推荐”的写法
坚持用字段名或别名，比如 ORDER BY score ASC 或 ORDER BY total ASC，哪怕多敲几个字母。
实际执行时，升序本身开销不大，但若字段没索引，大数据量下 ORDER BY 会触发文件排序（Using filesort），拖慢响应。真正容易被忽略的是：升序结果在分页（LIMIT OFFSET）场景下，必须配合索引才能稳定高效——否则每次 OFFSET 越大，性能越不可控。
