MySQL 5.7及更早版本、SQL Server、Oracle等不支持ORDER BY中直接使用子查询，会报“Subquery is not allowed in this context”错误；PostgreSQL部分支持但不可靠；稳定方案是将子查询提至SELECT列表用别名引用，或改用CASE WHEN、JOIN、CTE等方式实现。
ORDER BY 里直接写子查询会报错？先确认数据库是否支持
MySQL 5.7 及更早版本、SQL Server、Oracle 默认不支持在 ORDER BY 中直接使用子查询（尤其是含聚合或关联的），会抛出类似 Subquery is not allowed in ORDER BY clause 的错误。PostgreSQL 8.4+ 在部分上下文允许，但行为不可靠——比如子查询若含 LIMIT 或未明确关联，结果可能被优化器忽略或报错。真正能稳定用的，是「相关子查询」且返回单值，但前提是它必须出现在支持该语法的引擎中，并满足标量约束。
相关子查询做动态权重：必须满足三个硬条件
想让每行按自身上下文（如所属分类的平均点击量）计算排序值，得用相关子查询，但以下三点缺一不可：
- 子查询必须返回**单个标量值**（一行一列），否则触发
Subquery returns more than 1 row - WHERE 条件中必须有**显式关联**，例如
a2.category_id = a.category_id；漏掉就变成对每行都算全表均值，结果全一样，还极慢 - 关联字段（如
category_id）**必须有索引**，否则EXPLAIN会显示type: ALL，实际执行就是全表扫描
正确写法示例：
SELECT id, title, clicks FROM articles a ORDER BY ( SELECT AVG(clicks) FROM articles a2 WHERE a2.category_id = a.category_id ) DESC;
CASE WHEN 是跨库兼容的兜底方案
当数据库不支持 ORDER BY 中的子查询，或你无法控制执行环境（比如 ORM 自动生成 SQL），CASE WHEN 是唯一可靠的选择。它不依赖子查询语法，所有主流数据库都支持，且逻辑清晰可调试。
- 每个
WHEN分支返回同类型值（推荐整数），数值越小越靠前 - 别依赖
ELSE当“默认兜底”——它是真实权重，影响未匹配行的位置 - NULL 值必须显式处理，
job = NULL永远为 false，得写job IS NULL
例如按岗位优先级排序：
SELECT empno, ename, job, sal
FROM emp
ORDER BY
CASE
WHEN job = 'PRESIDENT' THEN 3
WHEN job = 'MANAGER' THEN 2
ELSE 1
END,
sal ASC;窗口函数不是 ORDER BY 的替代品，而是前置计算工具
有人误以为在 ORDER BY 里写 ROW_NUMBER() OVER (ORDER BY ...) 就能控制最终顺序，这是错的。窗口函数只影响其内部计算范围，不改变外层结果集的物理顺序。正确链路是：先用窗口函数生成权重列，再在外层 ORDER BY 引用它。
- 错误写法：
SELECT * FROM orders ORDER BY AVG(amount) OVER (PARTITION BY user_id)—— 语法非法 - 正确写法：把窗口结果作为派生列，再排序
示例：
SELECT order_id, user_id, amount,
AVG(amount) OVER (PARTITION BY user_id) AS user_avg
FROM orders
ORDER BY user_avg DESC, amount DESC;复杂点在于：相关子查询的性能是 O(N×M)，而窗口函数通常只需一次扫描；但窗口函数无法表达“先分组优先级、再组内排序”这类嵌套逻辑——这时候，CASE WHEN 仍是不可绕过的那一环。
