先分享一些实战经验：Oracle 21c 在别名排序方面严格遵循 SQL 标准，但其底层逻辑并非表面那么简单。许多开发者在实际项目中遇到问题，往往不是语法记错，而是对 Oracle 的解析顺序与别名作用域理解不足。
Oracle 21c 中 SELECT 别名不能在 ORDER BY 里使用带表达式的引用
Oracle 21c 依然遵循 SQL 标准：ORDER BY 子句可以引用 SELECT 列表中的列别名，但仅限于纯别名——即不带表别名前缀、未嵌套表达式的那种。例如，若写 SELECT salary * 1.1 AS adjusted_salary ...，那么 ORDER BY adjusted_salary 是合法的；但如果试图写 ORDER BY t1.adjusted_salary 或 ORDER BY adjusted_salary DESC NULLS LAST 这类带修饰的写法，在某些执行计划下可能报错或行为异常。
- 常见错误现象：
ORA-00904: "ADJUSTED_SALARY": invalid identifier——此问题多出现在子查询、WITH 子句或复杂视图中，因为 Oracle 解析器提前绑定了作用域，导致别名不可见 - 根本原因：Oracle 在解析阶段按 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY 的顺序处理，
SELECT中定义的别名在ORDER BY阶段才“生效”，但不支持跨层级引用——子查询外层的 ORDER BY 引用内层别名就会出错 - 安全做法：在
ORDER BY中直接复写原表达式，或确保别名定义在最外层查询中
子查询中 ORDER BY 引用别名失败怎么办
这是最常见的坑：很多人习惯将计算逻辑放入子查询，然后在外层用别名排序，结果报错。
SELECT * FROM ( SELECT employee_id, salary * 1.1 AS adj_sal FROM employees ) ORDER BY adj_sal; -- ✅ Oracle 21c 允许（最外层 SELECT 的别名）
但下面这个写法就会出错：
SELECT * FROM ( SELECT employee_id, salary * 1.1 AS adj_sal FROM employees ORDER BY adj_sal -- ❌ 报 ORA-00904：子查询内部不能使用自身 SELECT 别名做 ORDER BY );
- 子查询（非顶层）中禁止在
ORDER BY处使用本级SELECT的别名，因为子查询的排序对最终结果集无意义（除非配合FETCH FIRST使用） - 如果确实需要先排序再封装，改用
ROW_NUMBER() OVER (ORDER BY salary * 1.1)等窗口函数替代 - 或者干脆将排序逻辑挪到最外层：子查询只负责投影，排序交给外部的
ORDER BY
使用列位置编号（ORDER BY 1, 2）是否可靠
语法上可行，但不推荐用于生产环境。
ORDER BY 1表示按SELECT列表的第一个表达式排序，Oracle 21c 支持且解析效率不错- 问题在于太脆弱：一旦调整
SELECT字段顺序——比如开头加个dept_name——那么ORDER BY 1就指向了完全不同的列，且这类错误很难被及时发现 - 更糟糕的是，在含有
UNION的查询中，列位置编号仅对应第一个分支的字段顺序，后续分支的字段类型必须兼容，否则直接报错 - 建议仅用于临时调试或脚本生成场景，正式代码坚持用别名或显式表达式更稳妥
ORDER BY 中混用别名和表达式引发的隐式类型转换风险
这是一个容易被忽视的细节：当别名对应函数调用时——比如 TO_CHAR(hire_date, 'YYYY-MM')——在 ORDER BY 中直接使用该别名，Oracle 可能会按字符串字典序排序，而不是按日期逻辑排序。
- 例如：
SELECT TO_CHAR(hire_date, 'YYYY-MM') AS ym FROM emp ORDER BY ym——这个查询会将 '2023-10' 排到 '2023-2' 前面，因为它是按字符串比较的，而非真实时间先后 - 正确做法：在
ORDER BY中复写原始列，或使用明确的排序键，如ORDER BY hire_date，或ORDER BY EXTRACT(YEAR FROM hire_date), EXTRACT(MONTH FROM hire_date) - 别名只是显示标签，不会改变数据类型和语义；排序逻辑必须由实际值决定
别名排序看似省事，但 Oracle 对作用域、类型、执行计划的处理远比表面严格。真正稳定的写法，是让 ORDER BY 表达式与排序意图完全一致，而不是依赖解析器的“聪明”推测。
