MySQL 5.7及更早版本等不支持ORDER BY中直接使用子查询，应改用SELECT列表别名、JOIN预聚合或派生表等方式实现，避免性能劣化。
ORDER BY 里直接写子查询会报错
MySQL 8.0+ 和 PostgreSQL 支持 ORDER BY 中使用标量子查询，但 MySQL 5.7 及更早版本、SQLite、SQL Server（除非用 SELECT 列表里的别名）都会直接报错：Subquery is not allowed in this context。这不是语法写错了，是引擎限制。
实操建议：
- 把子查询提前到
SELECT列表中，用别名（如sort_priority），再在ORDER BY引用该别名 - 避免在
ORDER BY写多行子查询（比如(SELECT COUNT(*) FROM ...)），它可能被反复执行，拖慢排序速度 - 如果子查询依赖外层字段（相关子查询），确保外层表有合适索引，否则
Nested Loop会吃掉性能
用 JOIN 替代相关子查询做排序权重计算
当排序依据需要聚合或关联其他表（比如“按用户最近订单金额降序”），硬套子查询容易卡顿。JOIN 更可控，也更容易加索引。
常见错误现象：写成 ORDER BY (SELECT SUM(amount) FROM orders WHERE orders.user_id = users.id)，数据量一过万就明显变慢。
实操建议：
- 改用
LEFT JOIN预聚合：先SELECT user_id, COALESCE(SUM(amount), 0) AS total_spent FROM orders GROUP BY user_id，再和主表JOIN - 注意
LEFT JOIN后可能产生重复行，需配合DISTINCT或GROUP BY主键去重 - PostgreSQL 可用
LATERAL，MySQL 8.0+ 可用JOIN LATERAL，它们比相关子查询更易优化
ORDER BY CASE WHEN + 子查询组合业务规则
真实业务排序常含多级条件（比如“VIP 用户优先，其次看最近登录时间，最后按注册时间”），纯靠字段无法表达，必须用逻辑分支。
关键点在于：子查询必须返回单值（标量），且类型一致（比如都转成整数权重）。
实操建议：
- 用
CASE WHEN把子查询结果映射为可比较的数值，例如：CASE WHEN (SELECT 1 FROM vip_users v WHERE v.user_id = u.id) IS NOT NULL THEN 1 ELSE 0 END - 避免在
CASE分支里混用不同数据类型（比如有的分支返回字符串，有的返回数字），会导致隐式转换失败或排序错乱 - 如果子查询结果可能为
NULL，记得用COALESCE(..., 0)或IS NULL显式处理，否则整个CASE行为不可控
MySQL 5.7 下绕过子查询限制的临时方案
老系统没法升级，又必须动态算排序权重？只能把逻辑拆到应用层，或者用派生表（derived table）兜底。
性能影响很明显：派生表会物化中间结果，内存/磁盘开销大；应用层排序则丧失数据库的索引优势，且分页不准。
实操建议：
- 用
SELECT * FROM (SELECT ..., (SELECT ...) AS sort_val FROM t) AS tmp ORDER BY sort_val—— 这是兼容性最广的写法 - 给派生表加
WHERE条件时，尽量前置过滤，减少子查询执行次数 - 如果排序字段只是用于分页（如
LIMIT 20 OFFSET 100），考虑用游标分页（WHERE sort_col > ?）替代OFFSET，避免子查询重复计算
子查询排序真正难的不是语法，而是搞清哪一层在执行、执行几次、结果是否稳定。尤其在分页 + 关联 + 聚合混用时，一个没注意，EXPLAIN 里就冒出 Using filesort 和 Using temporary —— 那时候再调就晚了。
