ORDER BY 后面能跟哪些东西
MySQL 的
ORDER BY子句后面可以跟列名、列别名、表达式、数字位置（1-based），甚至函数调用，但必须确保排序依据在
SELECT结果集中可解析或语义明确。 列名：如
ORDER BY user_id—— 要求该列存在于表中或
SELECT列表中 列别名：如
SELECT name AS full_name FROM users ORDER BY full_name—— 仅在 MySQL 8.0+ 默认允许；5.7 中需开启
sql_mode中的
ONLY_FULL_GROUP_BY外部兼容项才稳定支持，否则可能报错
Unknown column 'full_name' in 'order clause'数字位置：如
SELECT id, name, age FROM users ORDER BY 3表示按第 3 列（
age）排序 —— 简洁但脆弱，一旦 SELECT 字段顺序调整就失效 表达式：如
ORDER BY LENGTH(name) DESC或
ORDER BY created_at + INTERVAL 1 DAY—— 支持，但会阻止索引使用（除非是生成列 + 索引）
ASC/DESC 是作用于单个字段还是整个 ORDER BY 列表
ASC或
DESC仅作用于紧邻其前的字段，不是整条
ORDER BY。多个字段排序时，每个字段可独立指定方向。
SELECT * FROM products ORDER BY category ASC, price DESC, updated_at DESC;
这表示：先按
category升序排；相同
category内，再按
price降序；仍相同时，再按
updated_at降序。漏写某个字段的排序方向，默认为
ASC，但显式写出更安全，避免协作时误解。
ORDER BY 在有 LIMIT 时为什么有时结果不稳定
当
ORDER BY字段存在重复值，且未覆盖全部排序维度时，MySQL 可能返回任意顺序的“并列行”，尤其配合
LIMIT使用时，分页结果会漂移（比如第2页突然出现第1页的某条记录）。 典型场景：
SELECT * FROM logs ORDER BY status LIMIT 10, 10—— 若上百条
status = 'pending'，MySQL 不保证它们内部顺序 解决方法：在
ORDER BY末尾追加一个唯一字段（如主键）作为决胜字段：
ORDER BY status, id注意：不要依赖
ORDER BY status, RAND()来“打乱”，它不解决稳定性，反而拖慢查询且无法利用索引
ORDER BY 性能差？先看执行计划和索引匹配
MySQL 是否走索引排序（
Using filesort消失），取决于
ORDER BY字段是否命中索引最左前缀，且 WHERE 条件未破坏索引连续性。
EXPLAIN SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC;
若
(user_id, created_at)有联合索引，则可避免
filesort；但若只有
created_at单列索引，或 WHERE 用了
user_id > 100这类范围条件，则大概率触发
filesort。 复合索引顺序很重要：想支持
WHERE a = ? ORDER BY b, c，索引应建为
(a, b, c)，而不是
(b, c, a)
ORDER BY b DESC, c ASC无法使用
(b, c)索引（MySQL 8.0+ 支持混合方向索引，但需显式声明
CREATE INDEX idx ON t(b DESC, c ASC)） 含函数的排序（如
ORDER BY UPPER(name)）基本无法走索引，除非建函数索引（MySQL 8.0.13+）：
CREATE INDEX idx_upper_name ON users ((UPPER(name)))
实际写 SQL 时，最容易被忽略的是：排序字段重复 + 缺少决胜字段 导致分页错乱，以及 索引列顺序与查询模式不匹配 导致隐形性能损耗。这两点不报错，但会让线上行为变得难以预测。
