MySQL原生全文索引不支持title列权重提升；需改用布尔模式重复关键词或应用层打分，PostgreSQL可用setweight()函数实现字段权重，ES则通过multi_match的fields参数配置。
MySQL 全文索引中怎么给 title 列设更高排序权重
mysql 原生全文索引（fulltext）不支持列级权重配置。你不能像 elasticsearch 那样用 boost: 2 直接提升 title 的匹配分值。所有参与 match ... against 的列在计算 relevance 时被同等对待，权重由内部算法（如词频、文档长度）决定，不可手动干预。
常见错误现象：SELECT *, MATCH(title, content) AGAINST('搜索词') AS score FROM posts ORDER BY score DESC 返回结果里 title 包含关键词的记录没排到前面——不是 SQL 写错了，是 MySQL 就不提供这个能力。
- 如果必须倾斜权重，得绕开原生
FULLTEXT，改用布尔模式 + 手动加权：把title字段重复拼进查询，比如AGAINST('+搜索词 +搜索词' IN BOOLEAN MODE)，相当于给 title 贡献双倍词频信号 - 更稳妥的做法是放弃
MATCH()的自动评分，改用LIKE或正则粗筛 + 应用层打分：比如标题匹配加 10 分，正文匹配加 3 分，再ORDER BY总分 - 注意：布尔模式下
+和-只控制是否必须/禁止出现，不改变排序分值；*通配只作用于词根，不放大权重
PostgreSQL 中用 ts_rank() 调整字段权重
PostgreSQL 的全文检索支持显式字段权重，靠 setweight() 函数实现。核心思路是：先为不同字段生成带权重的 tsvector，再合并，最后用 ts_rank() 计算综合得分。
使用场景：一张 articles 表有 title 和 body 字段，你想让 title 的匹配影响力是 body 的 3 倍。
- 建索引时不用特殊操作，但查询必须构造加权
tsvector：SELECT *, ts_rank(setweight(to_tsvector(title), 'A') || setweight(to_tsvector(body), 'D'), to_tsquery('搜索词')) AS rank FROM articles - 权重字母固定为
A（最高）、B、C、D（最低），对应系数默认是{1.0, 0.8, 0.6, 0.4}；可通过ts_rank(ARRAY[1.0, 0.5, 0.3, 0.1], ...)自定义系数数组 - 性能影响：每次查询都调用
to_tsvector()会触发实时解析，若字段长、数据量大，建议提前用生成列或物化视图缓存加权tsvector
为什么不要在 MySQL 里硬套 ORDER BY FIELD() 模拟权重
FIELD() 是用来做固定顺序排序的（比如 ORDER BY FIELD(status, 'draft','published','archived')），它和全文相关性完全无关。拿它来“强行把标题匹配的行往前排”，本质是业务逻辑硬编码，不是检索优化。
容易踩的坑：
- 写成
ORDER BY FIELD(id, (SELECT id FROM posts WHERE title LIKE '%词%'))—— 子查询不返回列表，直接报错Subquery returns more than 1 row - 试图用
CASE WHEN title LIKE '%词%' THEN 1 ELSE 0 END DESC排序：这只能做二值区分（有/无），无法体现“匹配程度”，且无法利用全文索引，全表扫描风险极高 - 混淆了“排序依据”和“检索依据”：全文索引加速的是
WHERE MATCH()过滤，ORDER BY在过滤后发生；用非索引字段排序，即使过滤快，最终排序仍可能慢
Elasticsearch 中 function_score 权重配置的关键点
ES 是少数真正支持细粒度字段权重的方案，但配置不当反而降低召回率或拖慢响应。重点不在“怎么写”，而在“什么时候该用”以及“参数怎么选”。
典型错误：把 title 字段的 boost 设成 10，结果含标题关键词但内容完全无关的垃圾帖排第一。
- 别单独 boost 字段，优先用
field_value_factor或script_score结合业务信号（如点击量、发布时间）做复合打分 - 如果坚持字段 boost，用
multi_match的fields参数比单字段boost更稳："fields": ["title^3", "content^1"]，注意^后面必须是数字，不能是变量 - 权重不是越大越好：
title^10可能让content完全失效；上线前务必用explain: true看实际score构成，确认各部分贡献合理
字段权重这事，没有银弹。MySQL 放弃幻想，PostgreSQL 精确但需理解权重系数映射，ES 强大但解释成本高——最容易被忽略的，其实是“相关性”本身是否真由字段位置决定，还是该交给用户行为数据校准。
