order by 后可直接写表达式，无需先在select中定义别名；但表达式无法自动走索引，需显式创建函数索引以提升性能，且注意mysql 5.7对不确定函数的限制及别名作用域陷阱。

ORDER BY 后直接写表达式是完全合法的

SQL 标准允许 ORDER BY 子句中直接使用列名、别名，也支持任意标量表达式——只要它在 SELECT 列表中逻辑可计算（不依赖未定义的运行时上下文）。数据库执行时会为每一行求值该表达式，再按结果排序。

常见误操作是把表达式写成字符串（比如 'price * quantity'），这只会按字面字符串排序；或者误以为必须先在 SELECT 中定义别名才能在 ORDER BY 里引用——其实不用。

• SELECT name, price, qty FROM items ORDER BY price * qty —— 按小计升序
• SELECT id, created_at FROM logs ORDER BY EXTRACT(YEAR FROM created_at) —— 按年份排序（PostgreSQL / Oracle）
• SELECT * FROM users ORDER BY CASE WHEN status = 'active' THEN 0 ELSE 1 END —— 把 active 用户排前面

MySQL 和 PostgreSQL 对表达式排序的支持差异

MySQL 8.0+ 和 PostgreSQL 都支持复杂表达式，但 MySQL 5.7 及更早版本对 ORDER BY 中的函数调用有隐式限制：若表达式含不确定函数（如 NOW()、RAND()），可能报错或行为异常；PostgreSQL 更严格，要求表达式必须是“确定性”的（deterministic），否则拒绝执行。

• 安全写法：ORDER BY ABS(x - y)、ORDER BY UPPER(name)、ORDER BY (a + b) / NULLIF(c, 0)
• MySQL 5.7 警惕：ORDER BY RAND() 虽能运行，但会导致全表扫描+临时文件排序，性能极差
• PostgreSQL 中 ORDER BY random() 是允许的，但同样会禁用索引，且每次执行结果不同——不是 bug，是设计如此

用别名简化长表达式，但注意作用域陷阱

在 SELECT 中定义列别名后，大多数数据库（包括 MySQL 8.0+、PostgreSQL、SQL Server）允许在 ORDER BY 中直接引用该别名。但要注意：别名不能在 WHERE 或 HAVING 中使用，因为它们的执行顺序在 SELECT 之前。

典型翻车场景：

SELECT id, title, (price * qty) AS total FROM orders WHERE total > 100 ORDER BY total;

上面语句在 MySQL 5.7 会报错 Unknown column 'total' in 'where clause'，因为 WHERE 看不到 SELECT 里的别名。正确写法是把表达式原样复制到 WHERE 中：

• WHERE (price * qty) > 100
• 如果表达式很复杂（比如嵌套 JSON 函数），建议用子查询或 CTE 提前计算，避免重复书写和维护困难

ORDER BY 表达式无法走索引，性能要提前评估

几乎所有数据库都不会为 ORDER BY 中的表达式自动创建函数索引（MySQL 8.0+ 支持函数索引，但需显式创建；PostgreSQL 支持表达式索引，SQL Server 支持计算列+索引）。这意味着 ORDER BY LENGTH(name) 或 ORDER BY SUBSTRING(email, 1, 3) 必然触发 filesort。

• 检查执行计划：MySQL 看 Extra 是否含 Using filesort；PostgreSQL 看是否出现 Sort 节点且没走 Index Scan
• 高频排序需求，优先考虑建函数索引：CREATE INDEX idx_users_name_len ON users(LENGTH(name))（PostgreSQL）
• 如果只是偶尔排序、数据量不大，不必强求索引——加索引本身有写入开销和存储成本

真正容易被忽略的是：同一个表达式，在 SELECT 和 ORDER BY 里各算一遍。如果涉及 JSON 解析、正则匹配或远程函数调用，开销可能远超预期。