order by 必须在 select 之后执行，因为排序对象是 select 阶段生成的最终列（含别名、聚合值、函数结果），而 where 和 group by 发生在 select 之前，无法引用尚未产生的别名。
ORDER BY 为什么必须在 SELECT 之后执行
因为 ORDER BY 排序的对象是最终要返回给用户的那组列——而这些列（包括别名、函数计算结果、聚合值）直到 SELECT 阶段才真正“生成”。数据库不可能对还没算出来的东西排序。
典型错误就是试图在 WHERE 或 GROUP BY 中引用 SELECT 里定义的别名，比如：SELECT price * 1.1 AS final_price FROM orders WHERE final_price > 100。这会报错，不是语法问题，而是执行顺序上 final_price 此时根本不存在。
ORDER BY 能用别名，但 GROUP BY 不能
这是最容易混淆的一点：你可以在 ORDER BY 中写 ORDER BY final_price，但不能在 GROUP BY 中写 GROUP BY final_price。
原因很直接：SELECT 阶段刚把 final_price 算出来，紧接着就进 ORDER BY；但 GROUP BY 发生在 SELECT 之前，它只能基于原始列或表达式分组，不能依赖尚未生成的别名。
常见踩坑场景：
- 写
SELECT user_id, MAX(created_at) AS last_login FROM logs GROUP BY user_id ORDER BY last_login DESC—— 合法，last_login是ORDER BY阶段可用的别名 - 写
SELECT user_id, MAX(created_at) AS last_login FROM logs GROUP BY last_login—— 报错，GROUP BY阶段last_login还没诞生 - 想按年份分组又按别名排序：
SELECT YEAR(order_date) AS y, COUNT(*) FROM orders GROUP BY YEAR(order_date) ORDER BY y—— 可以，因为GROUP BY和ORDER BY分别用了等价表达式，但注意：MySQL 允许GROUP BY y是特例（非标准 SQL），PostgreSQL 会拒绝
ORDER BY 影响索引是否生效
ORDER BY 看的是最终投影列，不是原始列。这意味着即使你在 ORDER BY 中用了别名或函数，数据库也得先算出结果再排序——无法直接走索引，除非原始列本身有合适索引且表达式可下推。
例如：SELECT id, UPPER(name) AS upname FROM users ORDER BY upname，哪怕 name 有索引，UPPER(name) 也无法利用该索引加速排序，因为索引里存的是原始 name 值，不是大写结果。
性能关键点：
- 如果排序字段来自原始列（如
ORDER BY created_at），且该列有索引，数据库大概率能用索引避免排序（Using index） - 如果排序字段是函数或别名（如
ORDER BY YEAR(created_at)），需要确认是否建了函数索引（MySQL 8.0+、PostgreSQL 支持） -
ORDER BY在LIMIT之前执行，所以ORDER BY x LIMIT 10仍需对全量结果排序，再取前 10 行——大数据集慎用无过滤的排序分页
ORDER BY NULL 是个隐藏优化手段
当明确不需要排序时，加 ORDER BY NULL 可以让 MySQL 知道跳过排序阶段。这在配合 GROUP BY 使用时特别有用——因为 MySQL 默认会对 GROUP BY 结果隐式排序，而很多业务其实不关心分组顺序。
例如：SELECT user_id, COUNT(*) FROM logs GROUP BY user_id ORDER BY NULL，比不加 ORDER BY NULL 的同语句快，尤其在用户量大的表上。
注意：ORDER BY NULL 是 MySQL 特有语法，其他数据库不支持；PostgreSQL 需用 ORDER BY (SELECT NULL) 或直接省略（默认不保证顺序）。
真正容易被忽略的，是 ORDER BY 对执行计划的“隐形控制”：它不只决定输出顺序，还可能触发临时表、文件排序（Using filesort），甚至改变索引选择策略。写的时候别只盯着结果对不对，得看 EXPLAIN 里有没有 Using filesort —— 那往往是性能拐点。
