应使用派生表或临时表预计算权重，避免在order by中嵌套子查询；mysql 5.7不支持with，需用带别名的from子查询固化权重，并确保关联逻辑在子查询内完成、null值用coalesce兜底。
子查询里怎么算动态权重而不拖慢查询
直接在 ORDER BY 里写复杂表达式或嵌套子查询，很容易让数据库重复计算权重，尤其当主表数据量大、权重逻辑涉及多表关联时，性能会断崖式下跌。真正可行的做法是把权重计算“提前固化”到排序前——要么用派生表（FROM 子句里的子查询），要么用 WITH 语句预计算。
- 避免在
ORDER BY中调用含 JOIN 或聚合的子查询，比如ORDER BY (SELECT score FROM weights w WHERE w.id = t.id)在 MySQL 5.7 下可能每行都执行一次子查询 - MySQL 8.0+ 和 PostgreSQL 支持
WITH，推荐写成WITH ranked AS (SELECT *, calc_weight(...) AS weight FROM table)，再对ranked排序 - 如果必须用相关子查询，确保子查询只查单值且有索引支撑，例如
(SELECT priority FROM user_config uc WHERE uc.user_id = t.user_id LIMIT 1)，且user_config(user_id)有索引
权重字段参与排序时 NULL 怎么处理
动态权重常来自左连接或条件计算，结果为 NULL 是常态。但 ORDER BY weight DESC 会让 NULL 排最前（MySQL）或最后（PostgreSQL），行为不一致，线上排序错乱往往就出在这儿。
- 显式控制
NULL位置：用ORDER BY weight DESC NULLS LAST（PostgreSQL/Oracle）或ORDER BY IFNULL(weight, 0) DESC（MySQL） - 更稳妥的是在子查询里统一兜底：
COALESCE(calc_weight(...), 0) AS weight，避免后续排序逻辑依赖数据库默认行为 - 警惕
NULL参与算术运算导致整行权重为NULL，比如base_score * factor中任一为NULL，结果就是NULL
MySQL 5.7 不支持 WITH，怎么写等效子查询
MySQL 5.7 没有 WITH，但可以用派生表（FROM 后的子查询）替代，关键是别让优化器把子查询“下推”成相关子查询——否则性能和可读性全崩。
- 写法必须带别名：
SELECT * FROM (SELECT id, name, @w:=calc_weight(...) AS weight FROM items) AS t ORDER BY weight DESC - 禁止在子查询里引用外层表字段，否则会退化成相关子查询；所有关联逻辑必须提前 JOIN 或用 LEFT JOIN 在子查询内完成
- 如果权重依赖用户会话变量（如当前登录用户偏好），改用临时表：
CREATE TEMPORARY TABLE tmp_weights AS SELECT ...，再 JOIN 主表，比反复计算更稳
PostgreSQL 中子查询权重与窗口函数混用的坑
想先按动态权重排序，再分页取 TopN？别直接在 ORDER BY 里套子查询然后加 LIMIT——PostgreSQL 的执行计划可能先 LIMIT 再算权重，导致结果不准确。
- 正确顺序：子查询算出完整权重 → 外层
ORDER BY weight→ 再LIMIT，例如SELECT * FROM (SELECT *, (SELECT w.val FROM weight_rules w WHERE w.tag = t.tag) AS wt FROM items t) s ORDER BY wt DESC LIMIT 10 - 若需同时做排名（如 RANK()），把权重计算放进
WITH，再在外层用窗口函数：WITH scored AS (SELECT *, calc_weight() AS w) SELECT *, RANK() OVER (ORDER BY w DESC) FROM scored - 注意子查询返回多行会报错：
ERROR: more than one row returned by a subquery used as an expression，务必加LIMIT 1或用MAX()等聚合兜底
实际跑起来才发现，权重公式里一个没加索引的关联字段，或者子查询少写了 COALESCE，就能让排序结果在不同环境表现不一致。
