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也会拖垮查询。
