rank()不能直接做加权排序，因其仅依据order by中已计算出的数值排序且不接受权重参数；需先用case、乘法等构造加权得分字段，再对它调用rank()。
为什么 RANK() 不能直接做加权排序？
RANK() 本身不接受权重参数，它只根据 ORDER BY 子句中表达式的值做纯数值排序，相同值得相同名次（跳号）。所谓“基于权重的排序”，本质是先用权重算出一个综合得分，再对这个得分排序——RANK() 只是排这个得分的结果，不是参与计算。
怎么构造带权重的排序字段？
常见做法是把各维度字段乘以对应权重后相加，生成一个 score 列，再用 RANK() 对它排序。比如标题匹配度权重 3、相关性分数权重 2、发布时间权重 1：
SELECT
id,
title,
relevance_score,
publish_time,
RANK() OVER (ORDER BY
(CASE WHEN title LIKE '%关键词%' THEN 3 ELSE 0 END) +
(relevance_score * 2) +
(DATEDIFF(CURDATE(), publish_time) * -1)
DESC) AS rank_num
FROM documents;
注意几点：
-
CASE WHEN比布尔表达式title LIKE ... THEN 1 ELSE 0更安全，避免隐式类型转换问题 - 时间越新，
DATEDIFF值越小，所以乘-1让新文档得分更高 - 所有参与加权的字段必须可比较、无
NULL；否则整行score会变NULL，被排到最后（或按数据库默认规则处理）
遇到 NULL 权重字段怎么办？
只要有一个加权项是 NULL，整个和就是 NULL，RANK() 会把它单独归为一组（通常排最末）。修复方式不是用 COALESCE 硬填 0（可能扭曲业务逻辑），而是明确补零逻辑：
RANK() OVER (ORDER BY COALESCE((CASE WHEN title LIKE '%关键词%' THEN 3 ELSE 0 END), 0) + COALESCE(relevance_score * 2, 0) + COALESCE((DATEDIFF(CURDATE(), publish_time) * -1), 0) DESC)
更稳妥的做法是在 WHERE 中提前过滤掉关键字段为空的记录，或者在应用层决定 NULL 字段是否应参与排序。
性能和可维护性容易被忽略的点
加权公式写在 ORDER BY 里，每次排序都重新计算，没有索引可用。如果数据量大：
- 考虑把加权得分存为生成列（MySQL 5.7+ 支持
STORED列），并为其建索引 - 避免在权重计算中调用函数如
LIKE或DATEDIFF—— 它们无法利用索引，且随数据量增长线性拖慢 - 权重系数别硬编码在 SQL 里，尤其当不同查询场景需要不同权重时，应由应用层传入参数，或从配置表读取
真正麻烦的从来不是写对 RANK()，而是让加权逻辑既符合业务预期，又不至于查一次卡三秒。
