oracle 21c中select别名仅支持在最外层order by中直接引用纯别名，子查询内order by不可用本级别名，应复写表达式或移至外层排序。
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 引用别名失败怎么办
这是最常踩的坑：把计算逻辑放在子查询里，再在外面 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）是否可靠
可以，但不推荐用于生产 SQL。
-
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 表达式和排序意图完全一致，而不是依赖解析器的“聪明推测”。
