order by 后可跟列名、列别名（8.0+默认支持）、数字位置（1-based）、表达式或函数；asc/desc仅作用于前一字段；重复值需加唯一决胜字段保分页稳定；索引需匹配查询模式以避免filesort。
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 时，最容易被忽略的是：排序字段重复 + 缺少决胜字段 导致分页错乱，以及 索引列顺序与查询模式不匹配 导致隐形性能损耗。这两点不报错，但会让线上行为变得难以预测。
