在个人博客或小型内容站点中，为成千上万篇文章提供快速检索是常见的技术需求。相比引入Elasticsearch这类重量级组件，直接使用SQLite内置的FTS5扩展能在不增加运维负担的前提下完成全文搜索。FTS5是SQLite从3.9.0版本开始提供的全文搜索引擎，它以虚拟表的形式存在，底层采用倒排索引结构，支持复杂的MATCH查询语法与排序权重控制。
搭建FTS5虚拟表与数据同步
要在博客项目中使用FTS5，第一步是创建一张虚拟表来存储需要被检索的字段。通常我们会把文章的标题和正文放进同一个FTS5表中，也可以额外增加作者、标签等辅助列。需要注意的是，FTS5表本身不强制定义数据类型，它更像是一个专门用于全文索引的容器。下面的示例展示了如何创建一张名为blog_search的表，并指定使用unicode61分词器，该分词器对英文及大多数拉丁字符支持良好，且能按Unicode边界切分词语。
对于已经存在于普通表articles中的历史数据，我们需要做一次全量同步。最直观的做法是编写一条INSERT SELECT语句，将原有数据插入FTS5表。如果博客系统采用写入时同步的策略，那么在新增或更新文章时，也要同步维护FTS5表的内容，否则会出现搜索结果和实际情况不一致的问题。为了降低复杂度，有些项目会选择触发器（trigger）来自动同步，但触发器在批量导入时可能带来性能损耗，需要结合业务场景权衡。
CREATE VIRTUAL TABLE blog_search USING fts5(
title,
content,
author,
tokenize='unicode61'
);
INSERT INTO blog_search (title, content, author)
SELECT title, body, author_name FROM articles;
-- 新增文章时同步
INSERT INTO blog_search (title, content, author)
VALUES ('SQLite入门', '介绍SQLite的基础用法', '张三');
在上面的代码中，blog_search并不实际存储原始数据页，它只保存分词后的索引信息。当你执行DELETE或UPDATE操作时，也必须针对FTS5表执行对应指令。很多初学者会直接修改articles表却忘了同步FTS5，导致搜出已删除的文章。因此，建议在数据访问层封装统一的保存接口，保证两张表的事务一致性。
中文分词与查询语法优化
unicode61分词器默认按空格和标点切分，对中文连续文本几乎无效，因为它不会把“博客全文搜索”拆成有意义的关键词。如果博客内容以中文为主，可以考虑使用第三方分词器如simple中文扩展，或者在应用层先做分词再写入FTS5的columns。另一种轻量做法是把中文内容按字切分存入FTS5，虽然索引体积变大，但能实现任意字串匹配。下面演示如何通过应用层将中文转为以空格分隔的字序列，再写入数据库。
FTS5的MATCH语法非常灵活，支持AND、OR、NOT以及前缀匹配。比如输入"SQLite OR 数据库"会返回包含任一词汇的文章；输入"搜*"则匹配所有以“搜”开头的词。在博客搜索框中，我们通常把用户输入直接拼为MATCH表达式，但要注意防止特殊字符引发语法错误。稳妥的方式是对用户输入做转义，或用fts5的query限制函数校验。以下代码展示了一个带前缀匹配的安全查询示例。
-- 按字切分后写入示例（应用层处理）
INSERT INTO blog_search (title, content, author)
VALUES ('博客 全文 搜索', '轻量 数据 库 实现 站内 检索', '李四');
-- 前缀查询
SELECT title, author FROM blog_search
WHERE blog_search MATCH '搜* OR 数据*'
ORDER BY rank;
rank是FTS5自动提供的隐藏列，用于表示相关度，值越小越相关。我们可以结合bm25辅助函数自定义排序权重，例如让标题命中比正文命中更重要。若博客同时支持标签过滤，还可以把标签作为普通列进行等值查询，与MATCH组合使用，从而缩小结果范围。需要避免的是在MATCH中拼接未经处理的用户输入，这可能被利用构造异常语法导致查询失败。
性能对比与落地建议
当文章量在十万级别以内时，SQLite FTS5的查询延迟通常可以控制在十毫秒级，远优于对原表使用LIKE '%关键词%'的全局扫描。LIKE不仅无法利用索引，还会在每次请求中遍历整段文本，且在中文环境下由于不能分词，常常返回大量噪声结果。下面的对照表列出了三种常见方案的差异，帮助你在技术选型时快速判断。
| 方案 | 部署成本 | 中文支持 | 实时性 |
|---|---|---|---|
| LIKE模糊查询 | 极低 | 差 | 高 |
| SQLite FTS5 | 低 | 需扩展 | 高 |
| 外部搜索引擎 | 高 | 好 | 中 |
从架构角度看，FTS5适合单体应用、静态站点生成器或Serverless函数内嵌数据库的场景。它的文件型存储让备份只需复制一个文件，迁移也异常简单。如果后续流量增长，需要将搜索独立出去，也可以把FTS5表导出为JSON再灌入专业引擎。实践中建议把搜索接口单独封装，未来替换实现不影响业务调用方。
另一个常被忽略的点是索引重建。当更换分词器或发现索引损坏时，可以使用INSERT INTO blog_search(blog_search) VALUES('rebuild')指令让FTS5重新构建全部索引，而不必删除表。配合定期优化命令，能长期保持查询效率。对于评论量大的博客，还可以把评论内容单独建一个FTS5表，避免正文索引过于臃肿。总体来看，用SQLite做博客全文搜索是兼顾成本与体验的务实选择。