ORDER BY 升序降序不必显式写 DESC，但强烈建议写；MySQL 默认 ASC，省略易致逻辑混乱、分页错乱；多列排序需注意 NULL 行为及索引对齐以避免 filesort。
ORDER BY 升序降序必须显式写 DESC？
不是必须，但强烈建议写。MySQL 默认按 ASC 升序，省略时行为一致，但一旦逻辑变复杂（比如多列混排、后续加字段），不写容易误判顺序。更关键的是：团队协作或代码审查时，DESC 不写就等于“看不见”，极易引发分页错乱、前端展示反直觉等问题。
-
ORDER BY create_time→ 实际是ORDER BY create_time ASC，最新数据在最后 -
ORDER BY create_time DESC→ 最新数据排最前，符合多数列表需求 - 混合排序如
ORDER BY status ASC, updated_at DESC：先按状态升序（比如 0/1/2），同状态内再按更新时间倒序
多列排序的优先级和空值陷阱
MySQL 严格从左到右执行排序：先比第一列，相等才比第二列，依此类推。但很多人忽略空值（NULL）的默认行为——它既不是最大也不是最小，在不同排序方向下位置会变。
- 升序（
ASC）时，NULL排最前；降序（DESC）时，NULL排最后 - 如果业务要求“空值统一放末尾”，不能依赖默认，得用表达式干预：
ORDER BY IF(ISNULL(priority), 1, 0) ASC, priority DESC - 真实案例：商品列表按销量排序，但部分商品销量为
NULL，若不做处理，它们会突然出现在顶部，干扰运营判断
用数字代替字段名排序靠谱吗？
语法上允许，比如 SELECT name, age, salary FROM employees ORDER BY 3 DESC 表示按第三列 salary 降序。但它极度脆弱：
- 一旦 SELECT 子句调整字段顺序（比如加了个
department在前面），ORDER BY 3就指向了错误列 - SQL 可读性归零，别人无法一眼看出排序依据，维护成本陡增
- ORM 或视图场景下，列序可能被重写，导致线上行为突变
结论：只在临时调试或极简脚本中用，生产环境一律用明确字段名。
ORDER BY 性能卡在哪？为什么加了索引还慢？
核心瓶颈常在 sort_buffer 内存不足，触发磁盘外部排序（Using filesort）。即使 WHERE 条件走了索引，只要 ORDER BY 字段不在该索引的最左前缀里，就大概率要额外排序。
- 查
WHERE city='杭州' ORDER BY name，仅city有索引 → 必走filesort - 建联合索引
(city, name)→ 可直接利用索引有序性，避免排序 - 注意：如果查询还包含
SELECT *或非索引覆盖字段，仍需回表，但排序本身已消除 - 可通过
EXPLAIN看Extra列是否含Using filesort，再调大sort_buffer_size（单线程有效）或优化索引
真正难缠的不是语法，而是排序字段和索引结构的对齐——写对语句只是第一步，没配好索引，再标准的 ORDER BY 也会拖垮查询。
