子查询中禁止直接使用ORDER BY（除非配合LIMIT或窗口函数），排序必须置于最外层；聚合结果排序需将聚合逻辑放入子查询，外层再ORDER BY；动态权重推荐归一化或线性组合而非CASE，注意NULL处理与性能优化。
子查询排序必须用 ORDER BY 套在最外层
SQL 不允许在子查询里直接写 ORDER BY（除非配合 LIMIT 或窗口函数），否则会报错或被忽略。想按聚合结果排序，得把聚合逻辑放进子查询，再在外层查一遍并加 ORDER BY。
- 错误写法：
SELECT * FROM (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id ORDER BY c DESC) t—— 多数数据库（如 MySQL 5.7、PostgreSQL）会直接报错 - 正确做法：聚合子查询只负责计算，排序留到外层：
SELECT * FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t ORDER BY t.cnt DESC - MySQL 8.0+ 和 PostgreSQL 支持子查询带
ORDER BY+LIMIT，但那只是为了取 Top-N，不是为排序语义服务
动态权重需要把聚合值转成排序系数，别硬写 CASE
所谓“动态权重”，本质是把多个聚合指标（比如订单数、平均金额、最近下单天数）合成一个可比数值。直接用 CASE WHEN 手动分段打分，后期难维护、边界易出错。
- 推荐用归一化或线性组合：
ORDER BY (cnt * 0.4 + avg_amount * 0.5 - recency_days * 0.1)，系数可配、可调、可解释 - 注意 NULL 处理：如果
avg_amount可能为 NULL，整个表达式会变 NULL，导致排在最前或最后（取决于数据库 NULL 排序规则），加COALESCE(avg_amount, 0)更稳 - 避免在
ORDER BY里重复写聚合函数，比如ORDER BY COUNT(*) + AVG(price)—— 这会触发多次计算，性能差，且部分数据库不支持
GROUP BY 和窗口函数混用时，ORDER BY 优先级容易搞反
想先按用户分组统计，再在整个结果集上按权重排序，但又想保留原始明细行（比如每个订单带用户权重），就得用窗口函数。这时候排序逻辑的位置特别关键。
- 错误理解：以为
ORDER BY写在含OVER()的窗口函数里就能控制最终顺序 —— 实际上它只影响窗口内计算（比如ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at)），不影响最终结果行序 - 正确链路：先用窗口函数算出权重列（如
AVG(amount) OVER (PARTITION BY user_id)），再在外层ORDER BY引用该列 - 示例：
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
ORDER BY 中引用子查询字段，别漏掉别名或表前缀
嵌套深了以后，外层 ORDER BY 很容易找不到字段，尤其当子查询用了聚合、重命名、或和外部表同名时。
- 必须显式给聚合列起别名，且外层引用时带子查询别名前缀，比如
(SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t ORDER BY t.cnt—— 漏掉t.在 PostgreSQL 会报错，MySQL 可能侥幸通过但语义模糊 - 如果子查询里有同名列（比如主表和子查询都有
id），不加前缀会导致歧义，数据库可能选错 - 别依赖 SELECT 列序号排序（如
ORDER BY 2）：可读性差，一旦子查询 SELECT 列顺序调整就崩，还容易被 SQL 格式化工具自动删掉
真正麻烦的不是写法，是权重公式随业务变——今天按复购率加权，明天要叠加登录频次和停留时长。每次改都得重新验算 NULL 行为、数据倾斜点、索引是否还能覆盖。这些没法靠一条 ORDER BY 解决，得提前把聚合逻辑拆进视图或 CTE 里留好钩子。
