可以，但仅限于postgresql、sql server、mysql 8.0+等主流数据库，且别名须在select中明确定义；mysql 5.7及更早版本不支持，oracle完全不支持。
ORDER BY 能不能直接用 SELECT 中的列别名？
可以，但仅限于大多数主流 SQL 引擎（如 PostgreSQL、SQL Server、MySQL 8.0+、SQLite），且该别名必须在 SELECT 子句中明确定义。标准 SQL 允许在 ORDER BY 中使用列别名，因为语义上它代表的是最终结果集的一列。
但注意：MySQL 5.7 及更早版本在严格模式下可能报错；Oracle 完全不支持在 ORDER BY 中直接引用 SELECT 别名（会提示 ORA-00904: invalid identifier）。
实操建议：
- 写法示例：
SELECT price * qty AS total FROM orders ORDER BY total DESC; - 如果目标数据库兼容性要求高（比如要同时跑在 Oracle 和 PostgreSQL 上），优先改用位置序号或重复表达式
- 别名若含空格或特殊字符（如
"order date"），需加双引号（PostgreSQL/Oracle）或反引号（MySQL），否则解析失败
用数字序号代替列名排序靠谱吗？
靠谱，而且是 ANSI SQL 标准支持的方式——ORDER BY 1 表示按结果集第 1 列排序，ORDER BY 2 DESC 表示按第 2 列降序。它绕过了别名兼容性问题，也避免重复写长表达式。
但隐患明显：
- 列顺序一变（比如在
SELECT开头加了个新字段），ORDER BY 2就指向了完全不同的逻辑字段，极难排查 - 可读性差，别人或一周后的你看不到排序依据是什么表达式
- 某些 ORM 或查询构建器（如早期 SQLAlchemy）对数字序号支持不稳定，可能生成错误 SQL
只建议临时调试或生成报表脚本等一次性场景中使用。
重复写表达式排序会不会影响性能？
绝大多数情况下不会。现代数据库优化器（PostgreSQL、SQL Server、MySQL 8.0+ 的 Cost-Based Optimizer）会识别出 ORDER BY price * qty 和 SELECT price * qty AS total 中的表达式相同，只计算一次，再复用结果排序。
不过仍有例外：
- 含不确定函数时（如
NOW()、RANDOM()），重复出现会被多次求值，导致排序结果不可预期 - 复杂子查询或标量函数（如自定义的
calculate_tax()）未被优化器内联，可能触发多次执行 - 在视图或 CTE 中嵌套多层时，部分引擎（如旧版 SQLite）可能无法跨层级识别表达式等价性
稳妥做法：如果表达式简单（如算术、内置函数），重复写没问题；如果涉及函数调用或子查询，宁可用别名（兼容前提下）或提前在子查询里计算好。
MySQL 5.7 升级后 ORDER BY 别名突然报错？
不是升级的问题，是默认 SQL 模式变了。ONLY_FULL_GROUP_BY 不影响别名，但 STRICT_TRANS_TABLES 或 ERROR_FOR_DIVISION_BY_ZERO 等可能间接暴露语法问题。真正原因通常是启用了 sql_mode=ANSI_QUOTES，导致双引号被当作标识符引号而非字符串，而你别名用了双引号却没配对。
快速定位和修复：
- 查当前模式：
SELECT @@sql_mode; - 检查报错信息是否含
Unknown column 'xxx' in 'order clause'—— 这说明 MySQL 没把别名当列名处理，大概率是版本低于 8.0 或未启用ANSI_QUOTES但误用了双引号 - 临时兼容方案：
ORDER BY (price * qty) DESC，明确写出表达式 - 长期建议：升级到 MySQL 8.0+ 并统一团队 SQL 编写规范，避免依赖模糊特性
别名排序看着省事，但数据库版本、模式配置、跨库移植这三关，漏掉一个就容易在上线前夜卡住。
