相关子查询可在ORDER BY中为每行计算动态权重，但必须返回单个标量值且含正确关联条件（如a2.category_id = a.category_id），否则报错或性能极差；普通子查询因只执行一次而无法实现行级权重计算。
相关子查询怎么给每行算点击权重
直接在 ORDER BY 里写相关子查询是可行的，但必须确保子查询返回单个标量值（不能多行或多列），否则会报错 Subquery returns more than 1 row。常见错误是忘了加 WHERE 关联条件，导致子查询对每行都扫描全表。
比如想按「当前文章所属分类下所有文章的平均点击量」作为权重排序，得这样写：
SELECT id, title, clicks FROM articles a ORDER BY ( SELECT AVG(clicks) FROM articles a2 WHERE a2.category_id = a.category_id ) DESC;
注意：子查询里的 a2.category_id = a.category_id 是关键关联——没有它，a 的每一行都会触发一次全表平均，结果全一样，且性能极差。
为什么不能用普通子查询代替相关子查询
普通（非相关）子查询在语句执行前就求值一次，结果对所有行都相同，起不到“每行独立计算权重”的作用。例如：
SELECT id, title, clicks FROM articles ORDER BY (SELECT AVG(clicks) FROM articles) DESC; -- 所有行权重都是同一个数
这种写法虽然语法合法，但完全失去动态性。真正需要的是“按分类内均值”“按作者历史均值”“按最近7天点击衰减分”这类行级上下文感知的计算，只能靠相关子查询实现。
容易踩的坑：
- 漏写关联条件，子查询退化为全表扫描
- 关联字段未建索引，
category_id或author_id缺少索引时，排序会极慢 - 子查询中用了
ORDER BY或LIMIT却没配合GROUP BY，MySQL 5.7+ 会直接报错
性能差的时候先看执行计划
相关子查询本质是 N×M 复杂度（主表 N 行 × 子查询平均 M 行），数据量稍大就卡顿。用 EXPLAIN 能立刻看出问题：
EXPLAIN SELECT ... ORDER BY (SELECT ... FROM articles a2 WHERE a2.category_id = a.category_id);
如果 Extra 列出现 Using temporary; Using filesort，说明 MySQL 不得不把中间结果落地再排序；更糟的是子查询那行显示 type: ALL ——代表没走索引，正在全表扫。
优化方向很明确：
- 确保子查询中的关联字段（如
category_id）有索引 - 把相关子查询逻辑提前物化成临时表或 CTE（MySQL 8.0+ 支持），避免重复计算
- 如果只是排序用、不需要返回权重值本身，考虑用
JOIN + GROUP BY预聚合替代，通常快一个数量级
ORDER BY 里嵌套子查询的兼容性边界
不是所有数据库都允许在 ORDER BY 里直接写相关子查询。PostgreSQL 和 MySQL 8.0+ 支持良好，但 SQLite 3.35 之前不支持；SQL Server 要求子查询必须加括号且不能含外部引用（需改用 APPLY）。
另一个隐性限制：子查询不能包含不确定性函数，比如 NOW()、RAND() 或用户变量 @var，否则排序结果可能每次执行都不一致，甚至报错 Invalid use of group function。
实际部署前务必在目标数据库版本上验证：SELECT 1 ORDER BY (SELECT COUNT(*) FROM dual WHERE 1=0) 这类空结果子查询是否被允许——有些旧版 MySQL 会直接拒绝空集子查询出现在 ORDER BY 中。
相关子查询的威力在于表达力，代价是容易失控。真要处理万级以上的动态权重排序，别硬扛，先拆成两步：聚合出权重表，再 JOIN 排序。
