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 解析、正则匹配或远程函数调用，开销可能远超预期。
