【金仓数据库征文】给国产数据库装上中文搜索引擎，zhparser vs jieba 分词实战，和三个隐藏关卡
一、别把全文检索外包给 Elasticsearch
很多系统一遇到中文模糊搜索的需求，第一反应就是上一套 Elasticsearch。多部署一个集群，多一条数据同步链路，多一个运维负担。但对相当一部分场景来说，这是杀鸡用牛刀。数据本来就在数据库里，为什么不让数据库自己做搜索？
金仓（KingbaseES）的多模能力里，藏着一个容易被忽略的模块，内置中文全文检索。两款中文分词器，zhparser 和 jieba，加上 GIN 倒排索引、相关性排序、关键词高亮，一套完整的搜索引擎基建，全在数据库内部。这篇我在鲲鹏服务器上把它跑通，对比两个分词器的真实差异，顺便趟过三个不写出来你一定会中招的坑。
二、两个分词器，切出两个世界
中文全文检索的第一道工序是分词，把「金仓数据库管理系统」切成一个个词。英文靠空格天然分词，中文没有空格，全靠分词器。金仓内置了两款，zhparser 是基于词性规则的分词器，jieba 移植自著名的结巴分词，走词典路线。
拿三句话做对比，大部分句子两边都切得对。比如经典歧义句「南京市长江大桥」，两者都正确切成南京市、长江大桥，没有切成南京、市长、江大桥。但有一句，把两者的差异暴露得干干净净。
原句: 金仓数据库管理系统 zhparser: '数据库':1 '管理系统':2 ← 「金仓」不见了 jieba: '数据库':2 '管理系统':3 '金仓':1 ← 正确切出「金仓」zhparser 把「金仓」弄丢了。这个细节先记住，第四节它要出大事。
三、第一个坑，||不是你以为的拼接
准备语料建索引的时候，我一头撞进了金仓 MySQL 兼容模式的经典陷阱。
我要把标题加正文拼起来送进分词器，顺手写了title || ' ' || body，结果返回一个f。
SELECT title || ' ' || body FROM articles WHERE id=1; -- 结果: f SELECT concat(title, ' ', body) FROM articles WHERE id=1; -- 结果: 金仓数据库迁移实战 把 Oracle...在 MySQL 兼容模式下，||是逻辑或，不是字符串拼接。字符串||字符串被当成布尔运算，结果是f，假。这个坑要是没发现，to_tsvector('jiebacfg', title||' '||body)实际是在给一个f分词，生成的索引全是空的，检索永远返回零结果，而且全程不报一个错。
正解是concat()。在金仓 MySQL 兼容库里做字符串拼接，一律concat()，永远别用||。改过来之后，倒排索引正常建立，12012 行文档就绪。
四、召回生死线，选错分词器内容整段消失
现在回收第二节埋的伏笔。同一批语料，同一个查询词「金仓」，分别用 jieba 索引和 zhparser 索引检索。
jieba 索引召回 5 篇含「金仓」的文章，zhparser 索引召回 0 篇。
零篇。
原因正是第二节那个差异。zhparser 切不出「金仓」这个词，索引里根本没有这个词条，查询的时候「金仓」被当成停用词忽略，召回自然是零。**一个词典缺失，就能让整类内容在搜索里彻底消失。**选分词器从来不是配置细节，是生死决策。对以专名、新词、行业术语为主的语料，政务、金融、科技类内容尤其如此，词典型的 jieba 通常是更安全的选择。
五、GIN 倒排索引，把全表扫描降到毫秒
搜索引擎的另一半是索引。全文检索用的是 GIN 倒排索引，和搜索引擎同源的数据结构。看实际效果，在 12012 行文档里查一个低选择率组合，向量 & RAG。
走 GIN 倒排索引: Bitmap Index Scan on idx_jieba → Execution Time: 1.9 ms 强制全表扫描: Seq Scan on articles → Execution Time: 4.7 msGIN 索引通过 Bitmap Index Scan 直接定位命中行，比全表扫描快 2.5 倍。这还只是 1.2 万行的小库。数据量越大、命中越稀疏，也就是越像真实搜索场景，倒排索引的优势就放得越大。几百万文档里搜一个关键词，GIN 是毫秒级，全表扫描可能是秒级甚至更久。
顺带一个我觉得挺有意思的观察。如果查询词命中率很高，比如查「数据库」能命中 42% 的文档，优化器会主动放弃索引，改走全表扫描，命中太多的时候索引反而不划算。金仓的优化器是懂全文检索代价的，不是无脑用索引。
六、排序与高亮，搜索的最后一公里
能搜到还不够，好的搜索要把最相关的排前面，把命中的词标出来。金仓两样都有。
相关性排序靠ts_rank，按关键词的词频、位置给文档打分。查数据库或迁移，标题里同时命中两个词的《金仓数据库迁移实战》拿到 0.0684 的最高分，排在第一，相关度低的排后面。搜索结果里最相关的在第一条，就是这么实现的。
关键词高亮靠ts_headline，把命中的词用标记包起来，直接生成搜索结果里那段带高亮的摘要。
第1篇: 业务系统平滑【迁移】到金仓，零停机完成数据校验与回退。 第2篇: 提供 MySQL 兼容模式，存量应用只需更换驱动即可【迁移】。第三个坑也埋在这里。我本想用round(ts_rank(...), 4)保留 4 位小数，结果全部返回0.0000。又是 MySQL 兼容模式的函数差异，round(小数, n)在这个模式下对纯小数返回 0，改用::numeric(6,4)强制类型精度才正常。数一下，这已经是本文撞上的第三个 MySQL 兼容模式的坑了，字符串的||、round，还有 tsvector 的||拼接操作符，也一样被逻辑或覆盖。
七、与 MySQL ngram 的正面对照
金仓的词典分词，和 MySQL 唯一的中文方案 ngram，到底差在哪？做一个对照实验就清楚了。查「据库」，它是「数据库」的一个片段，本身不是一个有意义的词。
KES jieba: 召回 0 篇 ← 词典知道「据库」不是词，精确地不匹配 MySQL ngram: 召回 4 篇 ← 「据库」是「数据库」里的合法二元组，全部误召回这一刀下去，两种机制的差别就露出来了。ngram 把文本切成固定长度的字符片段，默认 2 字，不理解词义。好处是不需要词典、召回全，代价是噪声大，「据库」这种无意义片段也匹配，索引体积还大。词典分词基于词典理解词边界，精度高、索引小，代价是依赖词典质量。
没有绝对的优劣，只有场景适配。但有一点是实打实的，金仓两种都给你，词性型的 zhparser 加词典型的 jieba，你可以按语料特性选，而 MySQL 只有 ngram 一种。多模融合这个词落到全文检索场景里，真实含义就是这种给足选择的能力。
八、结论
我用金仓内置的能力，给数据库装上了一个像模像样的中文搜索引擎。两款分词器可选，GIN 倒排索引毫秒级检索，相关性排序，关键词高亮，没有引入任何外部组件。
这趟实战最想留下两句话。
第一句，分词器的选择是搜索的生死线。jieba 召回 5 篇，zhparser 召回 0 篇，一个词典差异就能让整类内容从搜索里消失，选型必须拿真实语料实测，不能看文档拍板。
第二句，MySQL 兼容不等于完全一样。||、round这些运算符和函数的语义差异，会静默地毁掉你的功能，而且不报错。涉及它们的地方，永远亲手验一遍。
至于还在纠结要不要为了中文搜索再上一套 ES 的团队，我的建议是先看看金仓自己能不能扛下来。很多时候答案是能。数据不用搬家，搜索就在原地发生。这也是国产数据库多模融合给出的一个务实答案。