ORDER BY 不能直接引用 SELECT 别名，因 SQL 执行顺序中 ORDER BY 在 SELECT 列别名绑定后但不可回溯引用；PostgreSQL 等通过反向映射支持属扩展，Oracle 等严格遵循标准不支持；通用写法是重复表达式或用 CTE 固化别名。
ORDER BY 不能直接引用 SELECT 中定义的列别名，根本原因是 SQL 的逻辑执行顺序：ORDER BY 在语义上晚于 SELECT 子句的计算，但早于别名的实际“生效”时机——更准确地说，是标准 SQL 规定的执行阶段中，ORDER BY 属于查询处理中“排序阶段”，而别名是在 SELECT 列表求值后才被绑定到结果集的列名上，但该绑定对 ORDER BY 并不直接可见（尤其在未明确支持别名解析的数据库中）。
SQL 标准规定了严格的执行顺序
SQL 查询不是按书写顺序执行的。标准逻辑执行顺序大致为：
- FROM → ON → JOIN → WHERE
- GROUP BY → 聚合函数计算
- HAVING
- SELECT → 此时表达式被计算，别名被定义（但只是“输出列名”，尚未成为可被前序子句引用的符号）
- ORDER BY → 此时只能引用：原始表列、聚合结果（若已分组）、或 SELECT 中的表达式本身（而非别名）
也就是说，ORDER BY 发生在 SELECT 列别名“落地”之后，但它被设计为不能回溯依赖 SELECT 中的别名绑定——这是为了保持各子句之间的解耦和确定性。部分数据库（如 PostgreSQL、SQL Server）选择扩展支持别名引用，属于对标准的增强；而 MySQL（旧版本）、Oracle、SQLite 等则严格遵循标准，拒绝识别 SELECT 别名。
为什么有些数据库却允许用别名？
这并非 bug，而是实现层面的语法糖优化：
- PostgreSQL 和 SQL Server 在解析时会做“别名反向映射”：扫描 ORDER BY 中的标识符，若匹配 SELECT 列别名，则自动替换为对应表达式
- 这种支持需要额外解析开销，且可能引发歧义（比如别名与表中真实列同名时），所以不是所有数据库都实现
- MySQL 8.0+ 开始支持 ORDER BY 引用别名，但 5.7 及之前不支持；Oracle 始终不支持（除非用子查询/CTE 将别名“固化”）
安全、兼容的写法是什么？
想确保跨数据库可用，应避免依赖别名，改用以下方式之一：
- 重复表达式：ORDER BY SUBSTRING(name, 1, 1), age
- 用位置序号（仅限简单场景）：ORDER BY 1, 2（表示按 SELECT 第一、第二个表达式排序；MySQL、PostgreSQL 支持，但 SQL Server 不支持，Oracle 仅在某些上下文支持，不推荐用于生产）
-
用子查询或 CTE 提前固化别名：
WITH ranked AS (SELECT name, LENGTH(name) AS name_len FROM users)
SELECT * FROM ranked ORDER BY name_len;
一个小例子对比
下面语句在 PostgreSQL 中合法，在 Oracle 中报错 “ORA-00904: 'FULL_NAME' invalid identifier”：
SELECT CONCAT(first_name, ' ', last_name) AS full_nameFROM employees
ORDER BY full_name;
正确写法（通用）：
SELECT CONCAT(first_name, ' ', last_name) AS full_nameFROM employees
ORDER BY CONCAT(first_name, ' ', last_name);
