本人个人博客地址：Egg-blog

一、原方案的痛点与弊端

先看改造前的搜索接口实现，问题一目了然：

// 改造前：ArticleServiceImpl.searchArticleByContentList articles = articleMapper.selectList(
new LambdaQueryWrapper
.like // 全表扫描！.eq)，// 每次搜索还把分类表整张捞一遍
Map categoryMap = categoryMapper.selectList.stream...

1️⃣ LIKE '%keyword%' 前后通配。索引完全失效

前后都带通配符的 LIKE 无法走任何 B+ 树索引，每次搜索都是对 article_content字段的全表扫描。文章还少的时候无感，文本量上到几十万字以后每一次搜索都是对数据库的一次毒打。

2️⃣ 被迫用限流当遮羞布

因为查询太贵，接口只能挂 @AccessLimit 硬扛——每分钟最多搜 次使用者体验极差。限流的意义本该是防爬虫防滥用，结果变成了给慢查询擦屁股。

3️⃣ 藏了一个静默 bug

原实现里截取搜索摘要的逻辑是这样的：

int index = -1;// 定义在循环外，for {
index = content.toLowerCase.indexOf);...
}
if { // 只判断了最终一篇
return listVos;}
return List.of;

index 定义在循环体外循环结束后只剩最终一篇文章的命中状态——只要最终一篇没命中，哪怕前面全命中了也直接返回空列表。怎么说呢，搜索“偶尔抽风查不到”的灵异现象，根源就在这。

二、总体设计：面向接口的可插拔搜索架构

主要思路： 调用方只依赖抽象接口，搜索引擎可插拔、可降级。

ArticleController │ 只依赖接口
▼
┌─────────────────┐
│ SearchService │ ← 搜索引擎抽象层
└─────────────────┘
▲ ▲
│ @Primary │ 永远注册
┌──────┴────────┐ ┌───────┴───────────────┐
│ EsSearch │ │ NgramSearch │
│ ServiceImpl │──▶│ ServiceImpl │
│ │降级│
└───────────────┘ └───────────────────────┘

配置驱动。一行切换：

search:
engine这方面，ngram # ngram | es
说到es，host: 
port这方面，
再看scheme，http
index-name: blog_article

• @ConditionalOnProperty: ES相关Bean仅在es模式下装配；ngram模式零开销，
• @Primary: ES实现优先注入；ES异常时自动降级到ngram，实现无感知。
• 使用者痛点： 程序高并发时不再被限流卡住即使ES宕机也能自动回落到低成本备选方案。
• 使用者痛点： 查询速度从秒级提高到毫秒级，明显提高页面渲染体验。
• 使用者痛点： 避免“偶尔抽风查不到”BUG，让结果始终准确可靠。
• 使用者痛点： 不需要改动业务代码即可切换搜索引擎，只需修改配置文件即可。
• .try-catch结构确保即使ES出现异常也不会抛给前端错误，而是安全返回空列表或fallback结果；日志记录帮助运维快速定位问题。

@Override public List searchArticleByContent {
try {
return doSearch);} catch {
log.warn);try {
return ngramSearchService.searchArticleByContent;} catch {
log.error);return List.of;}
}
}

三、方案一：MySQL ngram 全文索引

原理

• Mysql内置ngram全文解析器。把文本按二元组切分建倒排索引，自然支持中日韩文本，无需部署新组件，是个人博客性价比之王。

建索引

ALTER TABLE `t_article` ADD FULLTEXT INDEX `ft_article_content` WITH PARSER ngram;

查询改造

• Mybatis-Plus 的 LambdaQueryWrapper 不支持 MATCH AGAINST，在 Mapper 手写语句。
  • // 双引号短语匹配；语义等同 LIKE '%keyword%'但走 ft_article_content 索引 @Select " + "AGAINST IN BOOLEAN MODE) " + "AND status = #{status} AND is_deleted = ") List searchByContentFulltext String keyword,@Param Integer status);/* * 注意： * keyword传入前必须清洗掉双引号和反斜杠，否则短语查询直接报废；* 最小长度从1改为2，因为ngram是二元切分；不过，*/ String cleanKeyword = keyword.replaceAll.trim;if ) { return List.of;} ` ` ` ` ` ` ` ` `

   
  
  两个细节这方面。
  
  
  短语匹配 ： AGAINST，ngram 会把短语切成 bigram 并要求连续出现，与原来 LIKE '%keyword%' 完全一致，但走的是索引；不过，
  
  
  输入清洗 ：双引号和反斜杠会破坏短语语法。需要洗掉，同时把关键词最小长度从1改成2。
  
  
  
  顺手修掉的历史欠账 
  
  
  循环外 index 的 bug：每篇文章各自定位命中位置截摘要，如果定位不到就取开头兜底；
  
  全表捞分类的观点是，改成按命中文章的 categoryId 批量 selectBatchIds。其实，
  
  
  适用边界 
  
  百万~千万字符级别、低 QPS 的个人博客。ngram 闭眼用，它的短板不在性能而在效果 ：二元切词不懂词语边界。相关度排序粗糙，没有高亮、同义词、拼音这些花活。要玩这些得上 ES，按理说，<\/strong>
  <\/
  <\/
  <\/
  <\/
  <\/
  <\/
  <\/
  ">