ORDER BY能用列别名是因为其执行顺序在SELECT之后，此时别名已生成；WHERE报Unknown column是因为它在SELECT之前执行，别名尚未存在，这是所有主流数据库遵循的统一执行顺序（FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY）所致。
ORDER BY 为什么能用列别名，而 WHERE 报 Unknown column
因为 SQL 的执行顺序不是从上到下读代码，而是有严格阶段划分：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。SELECT 阶段才生成列别名，所以只有在它之后的 ORDER BY 能“看见”这个别名；WHERE 发生在 SELECT 之前，此时别名根本不存在。
-
WHERE报错是必然行为，不是数据库 bug，MySQL/PostgreSQL/SQL Server/Oracle 全部一致 - 错误示例：
SELECT price * 0.9 AS discounted_price FROM products WHERE discounted_price > 100→Unknown column 'discounted_price' - 正确写法只能是重复表达式：
WHERE price * 0.9 > 100，或套一层子查询
ORDER BY 引用别名时的常见陷阱
别名在 ORDER BY 里看似方便，但容易掩盖语义和类型问题：
别名不能嵌套在表达式中：
SELECT name AS full_name FROM users ORDER BY UPPER(full_name)✅ 合法（full_name单独出现）ORDER BY full_name || '_test'❌ 多数数据库不认，会报Unknown column或解析为原始字段字符串拼接别名排序可能不符合数值直觉：
SELECT CONCAT(id, '-', name) AS id_name FROM users ORDER BY id_name
结果中"10-john"会排在"2-alice"后面（字典序），而非按id数值大小浮点计算别名排序不稳定：
SELECT ROUND(price * 1.07, 2) AS final_price FROM items ORDER BY final_price
若price是FLOAT，ROUND()可能返回带微小误差的值，导致排序抖动
哪些数据库真正在 GROUP BY 里支持别名？别信文档
MySQL 8.0+ 在非严格模式下允许 GROUP BY dept_name（对应 SELECT dept_name FROM ...），但这只是 parser 层的宽松处理：
- 不是 SQL 标准，PostgreSQL/SQL Server/Oracle 均不支持
- 升级 MySQL 或开启
STRICT_TRANS_TABLES后立即失效 - 在子查询、视图、CTE 中复用该写法大概率报错
- 真实可移植方案只有三个：
- 重复整个表达式（最稳妥）
- 改用原始列分组（牺牲语义清晰度）
- 用子查询提前把别名“落地”（推荐中等以上复杂度场景）
ORDER BY 位置序号（如 ORDER BY 1, 2）到底靠不靠谱
位置序号是语法糖，但跨数据库兼容性差、可维护性低：
- MySQL 和 PostgreSQL 支持，但遇到
UNION查询时，序号含义易混淆（以第一个SELECT的列数为准） - SQL Server 默认禁用位置序号，除非启用旧兼容模式
- SQLite 支持，但复合查询中行为不一致
- 最大风险：SELECT 列顺序一调，排序逻辑就 silently 错位，且无语法报错
真正容易被忽略的点是：*ORDER BY 中的别名引用，不会触发该表达式的重新计算——它只是 SELECT 输出列的快捷映射。如果你没在 SELECT 列表里显式写出 price 0.9，那这一列就不会出现在结果集中，哪怕你在 ORDER BY 里写了它。**
