什么是全文搜索 / 分词搜索？

在日常开发中，我们几乎每天都在使用搜索功能： 搜索文章、搜索商品、搜索聊天记录、搜索资源名称……

但真正当你需要自己实现搜索系统时，就会发现一个问题：

数据库的 LIKE '%关键词%' 根本不够用。

这时， 全文搜索 和 分词搜索 就登场了。

为什么传统 SQL 搜索不够用？

最原始的搜索方式通常是：

SELECT * FROM article WHERE title LIKE '%手机%';

这种方式存在几个明显问题：

1. 性能差 %关键词% 前后模糊匹配无法走索引，数据量大时查询极慢。
2. 匹配粗糙 只能按完整字符串匹配，无法理解词语边界。
3. 无法做相关性排序 结果无法按 匹配度 排序，只能返回全部命中记录。

当数据规模从几万增长到百万级，传统模糊匹配几乎不可用。

于是就需要 全文搜索引擎 。

什么是全文搜索（Full-Text Search）？

全文搜索 是指：

将文本内容进行索引处理，使系统可以像搜索引擎一样快速查找关键词，并按相关性返回结果。

它的核心思想是：

• 先建索引
• 再通过索引查找
• 不是实时扫描原始文本

这和普通数据库的 B+Tree 索引类似，但全文搜索使用的是 倒排索引（Inverted Index） 。

倒排索引是如何工作的？

假设有三条文本：

1. 我喜欢苹果
2. 苹果很甜
3. 我喜欢香蕉

倒排索引会变成：

当你搜索 喜欢 苹果 时：

• 喜欢 → 文档 1,3
• 苹果 → 文档 1,2
• 交集 → 文档 1

这就是全文搜索的本质。

速度快、可扩展、支持相关性评分。

什么是分词搜索？

在英文里，单词天然以空格分隔。 但在中文里：

我喜欢苹果

计算机并不知道该如何拆分。

所以必须先做一步：

把连续文本切分成有意义的词语

这一步就叫 分词（Tokenization） 。

例如：

我 / 喜欢 / 苹果

只有完成分词，倒排索引才有意义。

为什么中文必须做分词？

如果不分词，而是按单字索引：

我 / 喜 / 欢 / 苹 / 果

搜索 喜欢 时：

• 喜 → 文档 1
• 欢 → 文档 1

结果虽然能命中，但：

• 无法理解词语语义
• 相关性计算不准确
• 搜索 喜 也会命中 喜欢
• 精度极差

因此中文搜索必须有 分词器 。

常见分词方式

1. 词典匹配法

基于词库进行最大匹配或最小匹配。 实现简单，速度快，但依赖词库质量。

2. 统计分词法

基于概率、词频、隐马尔可夫模型。 能识别新词，但计算复杂。

3. 混合分词

结合词典 + 统计，是目前主流方式。

例如：

• IK 分词器
• jieba
• THULAC

全文搜索系统的完整流程

一套完整的全文搜索系统通常包括：

1. 文本采集 数据来自数据库、日志、爬虫等。
2. 分词处理 将文本切成词语。
3. 建立倒排索引 生成关键词 → 文档映射。
4. 搜索查询解析 对用户输入分词并匹配索引。
5. 相关性排序 按匹配度、热度、时间等综合排序。
6. 返回结果

这正是 Elasticsearch、Solr、Meilisearch 等搜索引擎的标准流程。

全文搜索能解决什么问题？

✔ 海量数据快速搜索 ✔ 支持模糊匹配与关键词组合 ✔ 支持相关性排序 ✔ 支持拼音、同义词扩展 ✔ 支持高并发查询

这也是：

• 电商搜索
• 内容检索
• 日志查询
• 磁力搜索
• 文档管理系统

的核心基础。

分词搜索与数据库搜索的配合

在实际项目中常见组合是：

• MySQL 负责结构化数据
• 全文搜索引擎 负责文本检索

搜索得到文档 ID → 再回查数据库详情 → 返回完整结果。

这种架构兼顾性能与灵活性。

总结

全文搜索的核心是倒排索引。 分词搜索是中文全文搜索的前置步骤。

当你的数据规模变大、搜索需求变复杂时：

传统 SQL 模糊查询会成为瓶颈， 而全文搜索系统才是真正的解决方案。

理解了分词与倒排索引， 你就已经掌握了搜索引擎最关键的底层原理。