MySQL无内置关键词权重排序函数，需人工构造得分表达式（如CASE WHEN+LIKE）实现；数据量大时应优先用FULLTEXT索引+MATCH AGAINST；复杂权重规则建议交由应用层处理。
MySQL 里没有内置的关键词权重排序函数
MySQL 原生不支持像 Elasticsearch 那样按关键词匹配度打分排序。ORDER BY 只能基于字段值或表达式计算结果排序，没法自动识别“标题中出现‘AI’比正文中出现更关键”这类语义权重。所以所谓“关键词权重排序”，本质是人工构造一个得分表达式，再按它排序。
用 CASE WHEN + LIKE 组合实现基础关键词权重
适合小规模、固定关键词、对性能要求不高的场景（比如后台管理搜几万条文章）。核心思路：给不同字段、不同匹配方式赋予不同分值，加总后排序。
常见错误现象：ORDER BY 里写多个 LIKE 导致全表扫描、无索引可用；或者用 INSTR() 判断存在却不区分位置和次数，权重失真。
实操建议：
- 优先用
CASE WHEN title LIKE '%关键词%' THEN 10而不是INSTR(title, '关键词') > 0—— 前者语义清晰，后者在某些版本中无法走索引 - 避免在
CASE中重复写同一关键词多次，容易漏改；可先用SELECT子查询或WITH（MySQL 8.0+）预计算字段 - 如果关键词含通配符（如
%或_），必须用ESCAPE处理，否则LIKE '%\%%' ESCAPE '\'
示例（MySQL 5.7+）：
SELECT id, title, content, (CASE WHEN title LIKE '%MySQL%' THEN 10 ELSE 0 END + CASE WHEN content LIKE '%MySQL%' THEN 3 ELSE 0 END + CASE WHEN title LIKE '%优化%' THEN 8 ELSE 0 END) AS score FROM articles WHERE title LIKE '%MySQL%' OR content LIKE '%MySQL%' ORDER BY score DESC;
FULLTEXT 索引 + MATCH AGAINST 是更靠谱的起点
当数据量上万、需要基本相关性（如词频、逆文档频率倾向），别硬写 CASE。MySQL 的 FULLTEXT 索引虽不如专业搜索引擎，但至少有内建的评分逻辑，且能走索引。
使用场景：博客、文档库等以自然语言为主的文本搜索；不适用于短代码片段、ID 搜索或需精确控制每个词权重的场景。
容易踩的坑：
-
CREATE FULLTEXT INDEX必须在MyISAM或InnoDB表上，且字段类型为CHAR/VARCHAR/TEXT - 默认最小词长是 4（
ft_min_word_len），搜 “SQL” 会失败；修改配置需重启 MySQL，线上慎动 -
MATCH(title, content) AGAINST('MySQL 优化' IN NATURAL LANGUAGE MODE)返回的是浮点相关性分数，不是整数权重，不能直接和CASE分数相加 - 布尔模式（
IN BOOLEAN MODE）支持+/-/*，但不返回分数，只过滤，排序得另想办法
复杂权重必须靠应用层补足
真正要实现“标题命中 ×2、首段命中 ×1.5、带标点结尾的匹配 ×1.2”，MySQL 很难干净完成。因为权重规则一多，SQL 就变得不可读、难维护、执行计划易劣化。
这时候更务实的做法是：
- 在 SQL 层只做粗筛：用
FULLTEXT或WHERE ... LIKE快速捞出候选集（比如前 1000 条） - 把候选数据拉到应用层（Python/Go/Java），用正则、NLP 库或自定义规则重新打分
- 内存排序后取 top-N 返回——只要候选集可控，整体延迟反而更低
尤其要注意：MySQL 对长文本的 LIKE 性能极差，content LIKE '%关键词%' 在没索引时等于全表扫大字段，IO 和 CPU 双爆。别指望加个索引就能救回来——LIKE '%...' 本身就用不上 B-tree 索引。
