不用再为文本搜索单独维护一套系统！全文检索深度解析

为了给商品、客服工单或者企业知识库增加一个搜索框，企业往往需要在业务数据库之外，再部署一套Elasticsearch。

数据库保存商品、订单和用户等真实业务数据，搜索引擎保存另一份文本索引；两套系统之间，还需要通过CDC、消息队列或者同步程序持续传输数据。一个看似简单的搜索需求，最后可能变成两套集群、两份数据和一条必须保持稳定的数据链路。

由此产生的问题并不少：数据库已经完成更新，搜索结果却可能尚未同步；业务查询同时涉及文本、库存、权限和订单状态时，应用需要在两个系统之间来回组合结果；企业还要承担额外的基础设施、数据存储、同步开发和运维成本。

平凯数据库（TiDB 企业版）正在通过全文检索改变这种默认架构。

平凯数据库将全文检索作为数据库原生的数据访问能力，使开发者可以直接通过SQL检索文本、按照相关性排列结果，并将文本搜索与权限、库存、租户、时间和交易状态等业务条件组合起来。

这意味着，大量常见的文本搜索需求，不一定再需要单独维护一套搜索系统。

它也标志着分布式数据库能力边界的一次重要拓展：数据库不再只是保存和查询结构化记录，还开始统一承载交易数据、文本内容、向量数据和AI检索工作负载。

全文检索最大的价值，不只是“查得更快”

提到全文检索，人们首先想到的往往是搜索性能。

例如，要从上亿条商品信息中寻找“无线降噪蓝牙耳机”，传统的模糊查询可能写成：

SELECT id, title FROM products WHERE description LIKE '%无线%' AND description LIKE '%降噪%' AND description LIKE '%蓝牙耳机%';

这类查询在数据量较小时可以满足基本需求，但随着数据规模和访问频率增加，局限会越来越明显。

• 首先，以通配符开头的模糊匹配很难充分利用普通B-Tree索引，可能需要扫描大量数据。
• 其次，模糊查询只能判断“匹配”或者“不匹配”，很难回答哪个商品与用户需求最相关。
• 再次，它缺少完整的文本分析能力，难以处理中文、英文、日文等不同语言，以及中英文混合内容。

全文检索通过专门的文本分析和索引机制，使系统能够快速定位包含关键词的文档，并根据相关程度对结果进行排序。

但对于企业来说，平凯数据库全文检索最重要的价值并不只是把查询从“慢”变成“快”，而是让搜索重新成为数据库能力的一部分。

过去，为了获得全文检索能力，企业通常要在数据库之外增加一套搜索引擎。现在，部分搜索需求可以直接在平凯数据库中完成，从而减少外部系统、数据复制和同步链路。

这是平凯数据库全文检索最具吸引力的地方：

• 减少一套需要部署、扩容和监控的搜索系统；
• 减少业务数据与搜索索引之间的同步程序；
• 降低数据更新延迟和结果不一致的风险；
• 减少重复存储以及相关基础设施投入；
• 让开发者继续使用SQL组织完整的业务查询。

因此，平凯数据库全文检索解决的不只是一个查询性能问题，更是一个数据架构问题。

原生SQL，让文本搜索真正进入业务查询

平凯数据库全文检索提供SQL接口。开发者可以在创建数据表时建立全文索引：

CREATE TABLE products ( id BIGINT, tenant_id BIGINT, title TEXT, price DECIMAL(10, 2), stock INT, status VARCHAR(20), FULLTEXT INDEX (title) WITH PARSER MULTILINGUAL );

查询时，可以使用全文检索函数寻找关键词，并按照相关性排列结果：

SELECT id, title, price, stock FROM products WHERE tenant_id = 1001 AND status = 'ON_SALE' AND stock > 0 AND FTS_MATCH_WORD('无线降噪耳机', title) ORDER BY FTS_MATCH_WORD('无线降噪耳机', title) DESC LIMIT 20;

这条SQL的意义并不只在于它能够搜索“无线降噪耳机”。

更重要的是，全文检索可以与租户、商品状态和库存等结构化条件放在同一条查询中。企业不必先从搜索引擎取得一批商品ID，再回到数据库检查商品是否上架、是否有库存，以及当前用户是否有权访问。

对于企业知识库，全文检索可以与部门和文档权限结合；对于客服系统，可以与工单状态、客户等级和处理时间结合；对于SaaS产品，可以与租户隔离和用户权限结合。

这正是数据库原生全文检索与外部搜索系统相比，最有辨识度的价值：搜索不再是一项与业务数据分离的外围能力，而是可以直接进入核心业务查询。

一次文本搜索，数据库需要完成什么

从开发者的角度看，全文检索可能只是一条SQL；但在这条SQL背后，系统需要完成文本分析、建立全文索引、匹配关键词和计算相关性等多个步骤。

第一步：分析文本

全文检索不能直接把一整段文字当成一个查询单位，而是需要先分析文本，识别可以用于检索的词语或者词元。

英文通常可以按照空格和标点进行切分。中文、日文等语言没有天然的空格边界，文本分析过程会更加复杂。

平凯数据库当前提供两类解析器：

• STANDARD：适用于以英文为主的内容，按照空格和标点切分文本；
• MULTILINGUAL：面向包括中文、英文、日文和韩文在内的多语言内容。

多语言解析能力对全球化电商、跨境SaaS和AI应用尤其重要。同一张表中可能同时保存中文商品标题、英文说明和日文评论，开发者不必预先为每条内容建立完全独立的检索链路。

第二步：建立全文索引

普通数据库索引通常用于快速定位某个字段值，而全文索引解决的是“哪些文档包含某个关键词”。

它会把文本与关键词之间的关系组织起来。搜索某个词时，系统不必逐条扫描所有原始文档，而是可以通过索引快速获得相关候选结果。

这也是全文检索能够在大量文本中保持查询效率的基础。

对于开发者而言，全文索引仍然通过熟悉的SQL方式创建和管理。数据库负责处理索引背后的文本分析和检索过程，应用不需要额外接入另一套查询语言与SDK。

第三步：计算相关性

搜索系统不只要找出“包含关键词”的内容，还要回答“哪些内容最相关”。

平凯数据库全文检索使用业界广泛采用的BM25算法进行相关性排序。BM25主要考虑三个因素：

• 一个关键词在当前文档中出现的情况；
• 这个关键词在所有文档中的稀有程度；
• 当前文档长度与平均文档长度之间的关系。

直观地说，一个只在少量文档中出现的关键词，通常比“的”“一个”这类常见词更有区分度；一篇集中讨论“分布式数据库”的文章，也应该排在只是偶然提到这个词的长文前面。

通过BM25，平凯数据库能够把搜索结果从简单的“命中列表”，变成按照相关程度组织的结果集合。

全文检索与向量检索，为什么缺一不可

生成式AI兴起之后，向量检索迅速成为数据库领域的重要能力。

向量检索可以把文字转换成向量，并按照语义相似度查找内容。即使两段文字没有使用完全相同的关键词，只要表达的含义接近，也可能被系统发现。

例如，用户搜索“怎样减少数据库扩容期间的业务中断”，向量检索可能找到一篇标题为“在线水平扩展最佳实践”的文章。两者用词不同，但语义相关。

不过，向量检索并不能替代全文检索。

当用户搜索产品型号、订单编号、邮箱地址、故障代码、版本名称或者专有名词时，精确关键词通常比语义相似度更加可靠。例如，“DeepSeek-R1”“平凯数据库 8.5”或者某个错误代码，都可能要求系统准确找到包含这些字符的内容。

两种检索方式各有优势：

• 全文检索擅长准确寻找关键词、名称、数字和专有信息；
• 向量检索擅长理解语义，寻找表达不同但含义相近的内容。

将两者结合，就形成了混合检索。

在RAG应用中，用户问题有时更偏向语义，有时则包含必须精确匹配的产品名称、数字和术语。只使用其中一种检索方式，都可能遗漏重要内容。混合检索可以同时获得关键词匹配结果和语义相似结果，再对候选内容进行融合与排序，从而为大模型提供更准确、更完整的上下文。

平凯数据库已经具备向量检索能力。随着全文检索加入，平凯数据库正在形成关键词检索、向量检索与结构化数据查询相结合的能力布局。

业务数据、文本内容和向量不必分散在多个系统中；搜索结果也可以直接与用户权限、订单状态、知识图谱关系以及其他业务数据组合。

对AI应用开发者来说，这比单独增加一种搜索算法更重要。它意味着支撑AI应用的数据架构有机会变得更加统一和简洁。

领先之处，不只是增加一个搜索函数

在数据库产品中支持全文检索，表面上看是增加了一种索引和查询函数。

但平凯数据库全文检索更值得关注的地方，在于平凯星辰正在重新定义分布式数据库可以承担的角色。

传统关系型数据库主要负责结构化交易数据；搜索引擎负责文本；向量数据库负责语义检索。企业为了构建一个完整的智能应用，往往需要组合多种系统，并不断在系统之间复制数据。

平凯数据库正在探索另一种产品形态：在同一个数据平台中，同时管理结构化数据、文本内容与向量数据，并通过SQL把关键词、语义和业务条件组织到同一条检索链路中。

这种领先性主要体现在三个方面。

• 第一，全文检索被纳入分布式数据库的原生能力体系。企业不必把文本搜索天然视为数据库之外的工作负载。
• 第二，搜索与业务数据可以直接结合。结果不仅与关键词相关，还能同时满足权限、库存、租户和交易状态等条件。
• 第三，全文检索可以与向量检索形成互补，为RAG、智能客服、企业知识库和AI Agent提供更加完整的检索基础。

因此，平凯数据库全文检索并不是让数据库简单增加一个“搜索框”，而是推动数据库从记录系统进一步演进为应用的数据上下文与智能检索平台。

哪些场景最适合平凯数据库全文检索

平凯数据库全文检索尤其适合文本搜索与业务数据紧密结合的场景。

电商与零售

搜索商品标题、属性和描述，同时结合库存、区域、价格、促销和上架状态过滤结果。

企业知识库

搜索制度文件、产品文档和技术资料，并根据部门、用户身份和文档权限控制可见范围。

客服与工单系统

检索历史问题、用户反馈和解决方案，同时结合客户等级、工单状态、产品版本和处理时间。

SaaS站内搜索

为不同租户提供隔离的文本搜索能力，并与现有账号和权限系统结合。

RAG与AI Agent

将全文检索与向量检索结合，既召回语义相近内容，也准确匹配名称、数字、版本和专有词，为大模型提供更可靠的上下文。

这些场景的共同特点是：文本搜索不是一个完全独立的系统，而是业务数据访问流程的一部分。

当全文检索需要频繁与结构化业务条件结合时，把搜索放回数据库的价值会更加明显。

平凯数据库会取代Elasticsearch吗

平凯数据库全文检索的目标，不应简单理解为全面取代Elasticsearch。

在复杂搜索运营、拼写纠错、搜索建议、高亮、分面导航、复杂聚合以及高度定制化文本分析等领域，专业搜索平台仍然拥有成熟的能力和生态。

平凯数据库全文检索带来的改变是：企业不必再把“增加全文检索”与“部署一套独立搜索引擎”画上等号。

如果业务只是需要为商品、工单、文章或知识库增加高质量文本检索，并且搜索结果需要与数据库中的交易、权限和状态数据紧密结合，那么平凯数据库可以提供一条更简单的技术路径。

换句话说，平凯数据库不是要替代专业搜索引擎的全部能力，而是让大量并不需要复杂搜索平台的业务，不必为了一个搜索框，多维护一套系统。

数据库正在成为智能应用的数据上下文平台

从在线交易到实时分析，从向量检索再到全文检索，现代数据库承载的数据类型和工作负载正在不断扩展。

全文检索进入平凯数据库，反映的并不只是一项功能变化，而是数据库产品边界的变化。

过去，数据库负责保存事实；搜索引擎负责寻找文本；向量数据库负责理解语义。如今，随着AI应用对实时数据、业务上下文和混合检索的要求不断提高，企业开始需要更统一的数据基础设施。

平凯数据库全文检索真正领先的地方，不是让数据库多了一种查询语法，而是让企业有机会把交易、文本、向量和AI检索放进同一个数据平台。

当数据库既能处理一笔交易，也能从海量文档中找到最相关的内容，并将结果直接交给业务系统或者大模型时，它已经不再只是一套记录系统。

它正在成为智能应用的数据上下文平台。