企业官网建设流程全解析

做后端这几年，搜索这块一直是"能用就行"的心态，直到上周线上一个 SpringBoot 项目的列表页被模糊查询卡到 800ms，被业务方追着问"能不能毫秒级"，我才真正把中文全文检索这件事从头到尾捋了一遍。这篇文章就是那次重构的记录：如何在 SpringBoot 里自建一套全文检索能力，让中文模糊搜索的响应稳定在毫秒级。方案不复杂，核心只有三件事：分词、倒排索引、缓存。我会把选型对比、关键代码、调优参数和踩过的坑都摊开讲，项目规模在百万级数据量以内的团队可以直接照着抄。

1. 先聊聊痛点：MySQL 的 LIKE 到底慢在哪

1.1 一次普通的模糊查询，问题现场还原

业务场景很简单：一张告警记录表，130 万行数据，页面上有个搜索框，用户输入任意关键词，要按标题字段做模糊过滤。最初实现就是最常见的WHERE title LIKE '%关键词%'，数据量在 20 万以内的时候没什么感觉，但到了百万级以后，打开页面明显能感到转圈，接口平均耗时 400ms 到 800ms，遇到并发稍高直接飙到两秒开外。

我刚开始也怀疑是慢查询没走索引，但即使给 title 加了全文索引，%关键词%这种写法依旧是全表扫描。MySQL 的 B+Tree 索引只能加速前缀匹配，也就是LIKE '关键词%'，一旦通配符放在最前面，优化器只能放弃索引，用整表扫的方式逐个判断。更麻烦的是，用户搜的是中文自然语言，就算你把字段做成前缀索引，搜索"项目管理"的时候用户也可能输入"项目""管理""目管"这类片段，前缀匹配根本覆盖不了这些输入习惯。

1.2 问题的三个本质：扫描、分词、索引结构

把这次慢查询拆开看，本质上是三个问题叠加。

第一个是扫描范围，%关键词%意味着每一行都要做字符串匹配，这是一个 O(n) 的操作，数据量线性增长，耗时也跟着线性上涨。第二个是缺少中文分词能力，MySQL 内置的全文索引对中文支持很弱，默认按字符切分，一个 10 个字的长标题会被切成一堆单字，搜"上海自来水"这种词时，它不知道"自来水"是一个语义单元，匹配出来的结果相关性乱得一塌糊涂。第三个是缺少倒排索引结构，关系型数据库的行式存储天生不适合做关键词检索，它擅长的是主键定位和范围扫描。

当时我列了一张对比表，把几种常见改进方案都过了一遍：

1.3 为什么最终没上 ES，而选择内嵌 Lucene

团队不是没考虑过 Elasticsearch，但项目只有 1 个 SpringBoot 服务，数据量 130 万，距离"需要分布式索引"的阶段还很远。上一套 ES 集群意味着要维护至少 3 个节点、处理分片策略、同步数据管道，为了一个列表页搜索框引入整套基础设施，性价比太低了。我更倾向于先验证一个思路：把索引建在应用本地，让检索只发生在一个进程内。

这就是我最后选择的方案：Lucene 内嵌索引 + HanLP 中文分词器 + Caffeine 热点缓存。Lucene 本身就是搜索引擎的底层引擎，Elasticsearch 的核心也是它，单机百万级文档的检索性能完全不成问题。把索引文件落在应用服务器的磁盘上，SpringBoot 启动时加载，请求直接命中本机索引，省去了网络开销和集群协调，这是响应能到毫秒级的大前提。

2. 中文分词的坑：Lucene 默认分词器根本不认识中文

2.1 分词是整个搜索体验的分水岭

开始动手后遇到的第一个问题就是分词。Lucene 自带的 StandardAnalyzer 把中文按单字拆分，搜"自来水"会被拆成"自""来""水"三个单独的 token，一个查询要把这三个字都命中才行，召回结果乱七八糟。这不是 Lucene 的错，它本身没有内置成熟的中文词典，需要我们自己接一个分词器。

网上经常被提到的是 IK Analyzer，老牌中文分词库，但维护频率一般，词典更新也慢。这次选型我用了 HanLP，主要是看中它中文支持完善、有标准分词和 NLP 分词等多套算法，而且针对行业词、人名、地名这些场景有现成词典。在 SpringBoot 里集成 HanLP 也很简单，引入依赖后直接调用分词接口就能拿结果。

2.2 HanLP 接入 SpringBoot：一段能跑的代码

Maven 依赖部分，只加上两个核心包，Lucene 版本和 HanLP 版本注意保持一致。

<dependency> <groupId>com.hankcs</groupId> <artifactId>hanlp</artifactId> <version>portable-1.8.4</version> </dependency> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-core</artifactId> <version>8.11.2</version> </dependency> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-analysis-common</artifactId> <version>8.11.2</version> </dependency> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-queryparser</artifactId> <version>8.11.2</version> </dependency>

HanLP 提供了一个HanLPTokenizer适配 Lucene 的 Tokenizer 接口，关键是把分词器配置到字段分析链路上。我单独建了一个配置类来管理 Analyzer，方便后续替换或增加同义词扩展。

@Configuration public class SearchAnalyzerConfig { @Bean("hanLpAnalyzer") public Analyzer hanLpAnalyzer() { return new Analyzer() { @Override protected TokenStreamComponents createComponents(String fieldName) { Tokenizer tokenizer = new HanLPTokenizer(); return new TokenStreamComponents(tokenizer); } }; } @Bean("searchIndexManager") public SearchIndexManager searchIndexManager( @Qualifier("hanLpAnalyzer") Analyzer analyzer) { return new SearchIndexManager(analyzer); } }

2.3 不只是"分词"这么简单：词库和停用词

分词器接上以后，测试时又暴露了一个问题：某些业务词汇被切错了。比如产品里的"运维工单"，HanLP 默认切成了"运维 / 工单"，看起来没问题，但"堡垒机"被切成"堡 / 垒 / 机"，搜"堡垒机"时因为查询也要分词，所以勉强能命中，但相关性打分很怪。

解决方式是为 HanLP 加载自定义词典。HanLP 支持在 classpath 下放自定义词典文件，每行一个词条，格式是"词语 词性 词频"。把业务术语批量录入后，分词效果立刻正常了。这里有个经验：词典要跟着业务走，不能只依赖通用词典。告警系统里的"CPU""内存""带宽"这类词属于通用词，不用管，但类似"工单号""设备SN"这种带业务属性的词，必须提前喂给分词器。

停用词同样重要。中文索引里 "的""了""和""是"这类词如果全量进入倒排索引，会白白膨胀索引体积，还会给相关性计算制造噪音。我通过停用词表把这部分 token 过滤掉，减少索引体积，也能提升检索精度。

3. 建立索引：从数据库数据到毫秒级检索的关键一步

3.1 文档建模的取舍

数据同步过来之后，先要设计文档字段。以告警记录为例，我建的 Lucene Document 大概长这样：

• id: 数据库主键
• titleKeyword: 标题原文，存 Keyword 类型，用于排序和兜底展示
• titleHanlp: 标题经过 HanLP 分词后的结果，用 TextField
• contentSummary: 正文摘要，同样走 HanLP 分词
• createTime: 毫秒时间戳，LongPoint 类型，供时间范围过滤
• alarmType: 告警类型，StringField 类型，精确匹配

这里有个很容易踩的坑：不要把原文和分词结果混在一个字段里。如果把原始标题存成 TextField，Lucene 会把整句当成一个很长的 token，既占空间又降低查询效率。我建议原文存一个字段，分词结果存另一个字段，查询时只搜分词字段，返回时展示原文。

3.2 全量索引 + 增量更新的运行机制

首次上线时要对历史数据做全量索引，我是用一个一次性任务，分页从数据库拉存量数据，批量写进 Lucene。130 万条数据大概跑了 2 分多钟，索引文件生成后落在配置好的目录下。

之后的数据变更走增量更新。写接口时新增一条记录，就同步调用 IndexManager.addDocument()，修改和删除也类似。这个流程里需要特别注意并发问题，Lucene 的 IndexWriter 不是线程安全的，我在管理类里用一个独立线程池串行处理所有写操作，避免多个线程同时拿到同一个 writer 导致锁冲突。

public void indexDocument(SearchDoc doc) { executor.execute(() -> { try { Document luceneDocument = buildDocument(doc); indexWriter.addDocument(luceneDocument); indexWriter.commit(); } catch (IOException e) { log.error("索引写入失败", e); } }); }

3.3 NGram 字段：这才是"模糊"搜索的灵魂

分词索引解决了"搜整词"的问题，但用户输入往往不是完整词。比如标题是"Kubernetes 集群节点异常"，用户可能搜"Kubernetes""集群""节点异常"，这些通过 HanLP 分词都能命中，但如果用户只记得一半，搜"群节"呢？HanLP 会把它切成"群 / 节"，两个单字去匹配索引，召回效果很不稳定。

为了覆盖这种中间片段的模糊搜索场景，我额外加了一个 NGram 字段。写入时把标题按连续滑窗切成长度为 2 到 4 的片段，比如"集群节点"会生成"集群""群节""节点"这些 NGram token。这样无论用户输入的是前缀、后缀还是中间片段，都能在索引里找到对应的 token。代价是索引体积会变大，实测 130 万条大约膨胀了 20%，但换来的检索覆盖面是值得的。

NGram 字段的实现不复杂，Lucene 提供了现成的 NGramTokenFilter，在自定义 Analyzer 里链式调用即可：

public class NGramAnalyzer extends Analyzer { @Override protected TokenStreamComponents createComponents(String fieldName) { Tokenizer source = new StandardTokenizer(); TokenStream filter = new LowerCaseFilter(source); filter = new NGramTokenFilter(filter, 2, 4, true); return new TokenStreamComponents(source, filter); } }

看到这里你可能会问：那还要 HanLP 分词干什么？两个字段作用不同。汉语言模型分词负责理解语义，处理"北京欢迎你"和"欢迎你到北京"这类需要词边界的问题；NGram 负责兜底碎片输入。两个索引字段配合，查询结果同时考虑两路信号，再用 Lucene 的评分机制综合排序。

4. 检索链路设计：让"模糊搜索"又快又准

4.1 查询构造：BooleanQuery 多字段组合

检索这一步，最忌讳的做法是拿着用户输入直接拼一个titleKeyword:*关键词*的 wildcard 查询。Lucene 里通配符查询虽然能用，但性能极差，因为*在最前面意味着要遍历大量词元做前缀匹配，数据量大一点就会重回秒级。

我的做法是把用户输入拆开，同时向多个索引字段发查询：

• 对输入用 HanLP 分词，得到一组语义词
• 对每个语义词，在 titleHanlp 字段上做 TermQuery
• 对输入原文，直接在 NGram 字段上用 TermQuery 做碎片匹配
• 各查询之间用 BooleanQuery 的 SHOULD 组合，让任意一路命中都能返回结果

这样做的好处是，既能命中完整词，又能命中用户输入一半的碎片，同时每一项都是 TermQuery，走的是倒排索引最直接的查链，性能远优于 wildcard。查询代码大概这样：

public SearchResult search(String keyword, int pageNum, int pageSize) { BooleanQuery.Builder builder = new BooleanQuery.Builder(); // 1. HanLP 语义分词查询 List<String> terms = hanLpTokenizer.segment(keyword); for (String term : terms) { builder.add(new TermQuery(new Term("titleHanlp", term)), BooleanClause.Occur.SHOULD); } // 2. NGram 碎片查询 builder.add(new TermQuery(new Term("titleNgram", keyword)), BooleanClause.Occur.SHOULD); builder.add(new TermQuery(new Term("contentNgram", keyword)), BooleanClause.Occur.SHOULD); // 3. 时间过滤条件，用 BooleanClause.Occur.MUST 强制 builder.add(LongPoint.newRangeQuery("createTime", startTime, endTime), BooleanClause.Occur.MUST); TopDocs topDocs = searcherManager.search(builder.build(), pageNum * pageSize); return convertResult(topDocs); }

4.2 排序策略：Lucene 自带评分 + 业务权重

搜索结果排序不能只靠 Lucene 默认的相关性。默认的 TF-IDF/BM25 会倾向于长度短的字段，一条只有"内存告警"四个字的短标题，往往比一条内容丰富但包含关键词的详细标题排得更靠前。我的处理是在返回阶段做一次二次排序：优先按业务规则评分。

具体做法是把业务权重量化成一个 scoreBoost 字段存进文档，比如"重要告警 +10""普通告警 +1""已恢复 +0.5"，查询取回 TopN 之后，在内存里用"基础分 boost 因子 + 业务分"重新排一遍。因为百万级数据下 Lucene 召回 Top 200 再在内存排序，开销很小，但用户体验会好很多，重要告警不再被淹没。

4.3 高亮与摘要：别把全文捞出来

搜索接口不是只返回列表，页面还要显示命中的关键词高亮，这需要从索引里拿出原文片段。这里有一个性能陷阱：如果用 Lucene 自带的 Highlighter 对每个结果重新分析原文，100 条结果就要做 100 次分析，接口耗时会明显上升。

我的办法是索引写入时额外存一个 preHighLight 字段，把标题和摘要的原文切片按句号、逗号切成短句存起来。返回结果时搜索命中分词的字符位置，只从包含关键词的短句里截取前后 60 个字作为摘要，彻底避开 Highlighter 的重复分析。视觉效果差不多，性能差了好几倍。

5. 毫秒级响应背后：索引管理、缓存与实测数据

5.1 复用 SearcherManager 别每次 new IndexSearcher

Lucene 使用中一个比较普遍的低级错误，是每次请求都创建一个新的 IndexReader。IndexReader 加载时会全量读取索引文件的段信息，百万级索引在机械盘上能吃掉几百毫秒，这样每次查询都被拖累成了慢查询。

正确做法是使用 SearcherManager 统一管理 reader 的打开和释放。构建好 SearcherManager 后，每次查询通过acquire()拿 searcher，执行完用release()归还，只在数据变更提交后调用maybeRefresh()刷新 reader。这样可以保证查询不重复加载索引文件，冷启动后再也见不到 "search too slow" 的现象。

5.2 Caffeine 热点缓存：让重复搜索稳定在亚毫秒

即使索引查询已经到了 50ms 左右，仍然有优化的空间。既然用户搜得最多的往往是那几十个热词，那就把它们的查询结果缓存进本地内存。我选了 Caffeine，它淘汰策略比手写 ConcurrentHashMap 靠谱，支持基于频率的 LFU，不常用的词自动清理，不会撑爆堆内存。

缓存键设计成了"关键词 + 页码 + 筛选条件"的拼接串，值就是排序完成后的前 100 条结果。设置 expireAfterWrite 为 60 秒，所以同一热词在一个窗口内直接返回缓存结果，整个接口耗时降低到 3ms 以内。命中率我看了一下日志，热词缓存命中率大约在 20%，虽然比例不高，但把最卡的部分稳住了。

5.3 实测数据：400ms 到 10ms 的对比

我把整个流程重构前后做了一组对比压测，机器配置是 4C8G 的普通服务器，数据量 130 万条，搜索关键词选的是比较常见的中文词"内存告警"。结果如下：

这个数据在百万级数据量下非常有参考价值。即使冷查询只需要 50ms 左右，也比原来的 480ms 快了近 10 倍，加上缓存之后基本是"无感"了。

5.4 JVM 参数与写索引线程的配套调优

为了让 Lucene 索引不至于拖垮应用进程，几个 JVM 参数也值得改。IndexWriter 的 RAMBufferSizeMB 我调到了 128MB，这样批量写入时内存能攒够一批再落盘，减少磁盘随机写次数。同时把 merge 线程数控制在一个，因为小规格服务器上 CPU 核数有限，merging 和查询并发会抢资源。

GC 方面，因为 Lucene 的查询会产生不少短命对象，建议使用 G1 垃圾回收器并开启-XX:+UseStringDeduplication，能减少相同关键词字符串的重复内存占用。这些参数不需要很精通 JVM 也能抄，直接放在启动脚本里即可。

6. 上线以后才遇到的坑：大索引的深分页、段合并与多实例部署

6.1 深分页别再用 from + size

原来 MySQL 分页翻到后面几页性能差，Lucene 也有类似的问题。TopDocs从第 10000 条开始取数据时，Lucene 仍然要完整计算前面所有文档的得分再丢弃，页数越深越慢。

解决方案是改用searchAfter机制：第一次查询拿 TopDocs，返回结果最后一篇文档的 score docID 作为游标，翻页时把它传进去，Lucene 直接从游标位置往后取。搜索框场景下用户很少有深度翻页需求，但后台导出、数据核对偶尔会有人翻到几百页，这个改动顺手就能做完。

6.2 段合并引发的查询毛刺

上线后我注意到，凌晨两点左右会出现一次查询耗时超过 200ms 的毛刺。查了监控之后发现，是 Lucene 在后台执行段合并，把多个小索引段合并成大段以提升后续检索效率，合并瞬间磁盘和 CPU 都被占住极大一部分，查询就被顶起来了。

Segment merge 不是坏事，但要给它安排合适的时间窗口，避免和业务高峰冲突。在索引配置里通过MergePolicy把合并任务的触发时机限制在每天凌晨 3 点到 5 点之间执行，同时把单个 merge 线程的并发数调低，查询毛刺立刻消失。

6.3 多实例部署时索引文件的并发写冲突

项目上线自然是双节点部署，但 Lucene 索引文件如果两个实例都去写，就会遇到LockObtainFailedException，两个进程同时争夺 write.lock，结果就是服务反复重启。

我的解决方式是在架构上单独让一个实例负责索引写入，另一个实例只读查询，读写分离。如果你不想引入额外的协调组件，就用一个简单的 ShedLock 定时任务保证只有主实例执行增量更新，副实例定时同步索引目录后加载。多实例部署宁可让搜索数据有 30 秒延迟，也不能让索引文件损坏。

这里还是那句话：方案从简开始，规模到了再换更重的手段。如果你的项目数据量已经到千万级甚至亿级，再考虑引入独立的 Elasticsearch 集群也不迟，逻辑依然是"分词 + 倒排索引 + 缓存"这套核心，只不过把索引从本地挪到了分布式存储上。

最后分享一个实际操作中的小习惯：重建索引后不要急着开流量，先跑一遍巡检查询脚本，把每个索引字段的 term 数量、空值比例、命中失败率打出来看一眼。我总能在这一步发现业务脏数据导致的分词异常或字段类型配置错误，省去线上排障的功夫。这套方案本质上是把复杂问题拆成了"中文理解"和"索引查询"两件事，每一件都不需要造轮子，但组合起来效果立竿见影。