活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# GBase 8c 做中文检索，别只剩 LIKE 在硬扫

我最近看 GBase 8c 全文检索资料时，比较有感触的一点是：很多业务系统已经存了大量中文文本，但查询方式还停留在 `LIKE '%关键字%'`。数据量小的时候能忍，表一大、字段一长、组合条件一多，LIKE 就很容易变成全表扫描。真正落到检索类需求时，中文分词、全文索引、搜索表达式这些能力要尽早纳入设计。

GBase 8c 提供全文检索能力，并且包含适合中文和中英混合场景的解析器。对日志摘要、工单内容、客户反馈、知识库标题、商品描述这类字段，如果还按普通字符串模糊匹配处理，后期性能和相关性都会比较难控。

## LIKE 适合简单匹配，不适合检索系统

`LIKE` 不是不能用，而是边界要清楚。

| 查询方式 | 适合场景 | 不适合场景 |
| --- | --- | --- |
| `col LIKE 'abc%'` | 前缀匹配、编码类字段 | 自由文本检索 |
| `col LIKE '%abc%'` | 小表临时查询 | 大文本字段高频查询 |
| 正则匹配 | 少量复杂规则筛选 | 高并发搜索入口 |
| 全文检索 | 文档、标题、描述、工单内容 | 需要精确逐字节匹配的字段 |

中文文本还有一个特点：词与词之间没有天然空格。英文场景按空格切词就能解决一部分问题，中文场景如果不做专门解析，很多搜索体验会很别扭。比如用户搜“数据库性能”，系统到底应该匹配“数据库”“性能”，还是只匹配完整连续字符串，这需要检索方案提前定义。

## 先把文本列分层

我自己做设计时，会先把文本列分成几类，不会所有字段都上全文索引。

| 文本类型 | 示例 | 推荐处理 |
| --- | --- | --- |
| 编码、编号 | 订单号、客户号 | B-tree 或普通等值/前缀匹配 |
| 短标题 | 工单标题、知识标题 | 可考虑全文索引 |
| 长正文 | 反馈内容、说明文本 | 适合全文检索 |
| 状态枚举 | 已完成、处理中 | 普通字段，不需要全文 |
| JSON 或拼接文本 | 扩展属性 | 先治理结构，再考虑检索 |

如果把所有字段都拼成一个大文本做搜索，初期很省事，但后面相关性排序、权限过滤、字段权重都会变得难处理。我更倾向于明确哪些字段参与检索，并保留原始结构。

## 一个工单检索的例子

假设有一张工单表，用户经常按标题和内容搜索中文关键词。

```sql
CREATE TABLE app_ticket.ticket_info (
    ticket_id      bigint PRIMARY KEY,
    title          text,
    content        text,
    ticket_status  varchar(32),
    created_at     timestamp,
    search_doc     tsvector
);
```

可以把标题和正文转换成全文检索向量。标题通常权重更高，正文权重稍低。实际项目里权重设计可以更细，这里只保留核心思路。

```sql
UPDATE app_ticket.ticket_info
SET search_doc =
    setweight(to_tsvector('ngram', coalesce(title, '')), 'A') ||
    setweight(to_tsvector('ngram', coalesce(content, '')), 'B');
```

查询时使用 `tsquery` 与 `tsvector` 匹配，而不是拼接 `%关键字%`。

```sql
SELECT
    ticket_id,
    title,
    ticket_status,
    created_at
FROM app_ticket.ticket_info
WHERE search_doc @@ plainto_tsquery('ngram', '数据库 性能')
  AND ticket_status &lt;&gt; 'DELETED'
ORDER BY created_at DESC
LIMIT 20;
```

这里用 `coalesce` 是为了避免某个字段为 NULL 后影响整体表达式。GBase 8c 文本检索资料里也提醒过类似处理思路，中文场景尤其容易遇到部分字段为空的情况。

## 全文索引要配合更新策略

如果检索字段经常更新，`search_doc` 也要同步维护。常见方式有三种。

| 方式 | 优点 | 风险 |
| --- | --- | --- |
| 查询时动态 `to_tsvector` | 不用维护冗余列 | 大表查询成本高 |
| 写入时应用同步生成 | 逻辑可控 | 应用和数据库规则容易不一致 |
| 数据库触发器维护 | 规则集中 | 高频写入时要评估开销 |

我更倾向于把 `search_doc` 作为一列存下来，并在写入或更新时维护。这样搜索时不用反复解析长文本。

```sql
-- 更新单条工单时同步刷新检索向量
UPDATE app_ticket.ticket_info
SET title = '数据库响应变慢',
    content = '业务高峰期查询延迟升高，需要排查执行计划和等待事件',
    search_doc =
        setweight(to_tsvector('ngram', coalesce('数据库响应变慢', '')), 'A') ||
        setweight(to_tsvector('ngram', coalesce('业务高峰期查询延迟升高，需要排查执行计划和等待事件', '')), 'B')
WHERE ticket_id = 10001;
```

如果是批量导入知识库，可以在导入结束后统一刷新 `search_doc`，再建或维护索引，避免逐行更新带来额外压力。

## 检索条件不要脱离业务过滤

全文检索只负责“文本匹配”，不应该替代业务条件。比如工单系统里，用户只能看自己部门的数据，或者只能看未删除、已发布的文档。这些过滤条件要和全文条件一起写，而且索引设计也要考虑组合过滤顺序。

```sql
SELECT ticket_id, title, created_at
FROM app_ticket.ticket_info
WHERE tenant_id = 'T001'
  AND ticket_status IN ('OPEN', 'PROCESSING', 'CLOSED')
  AND search_doc @@ plainto_tsquery('ngram', '连接超时')
ORDER BY created_at DESC
LIMIT 20;
```

如果先全文匹配出大量数据，再在应用层过滤权限，既浪费数据库资源，也容易引入越权风险。

## 中文检索要提前定义预期

中文搜索容易出现“用户以为应该搜到，系统没有搜到”的争议。我的做法是把检索规则提前写清楚。

| 规则项 | 需要确认的问题 |
| --- | --- |
| 分词方式 | 中文、英文、数字、混合文本怎么切 |
| 大小写 | 英文是否忽略大小写 |
| 停用词 | “的”“了”“和”是否参与检索 |
| 同义词 | “数据库”和“DB”是否等价 |
| 排序 | 按时间、相关性还是综合排序 |
| 高亮 | 是否需要返回命中片段 |
| 权限 | 检索前过滤还是检索后过滤 |

GBase 8c 提供能力是一部分，业务体验还要靠规则落地。尤其是知识库和客服检索，相关性排序可能比单纯命中更重要。标题命中、正文命中、近期文档、已验证文档，可以设置不同权重。

## 从 LIKE 迁到全文检索的处理顺序

我一般不会一次性把所有 LIKE 改掉，而是先挑高频、慢、文本字段长的查询下手。

| 步骤 | 动作 |
| --- | --- |
| 1 | 找出高频 `LIKE '%xxx%'` 查询 |
| 2 | 确认字段类型和文本长度 |
| 3 | 设计参与检索的字段和权重 |
| 4 | 增加 `tsvector` 列或表达式 |
| 5 | 建索引并刷新历史数据 |
| 6 | 灰度替换查询语句 |
| 7 | 观察命中率、延迟、用户反馈 |

示例改造前：

```sql
SELECT ticket_id, title
FROM app_ticket.ticket_info
WHERE title LIKE '%连接超时%'
   OR content LIKE '%连接超时%'
ORDER BY created_at DESC
LIMIT 20;
```

示例改造后：

```sql
SELECT ticket_id, title
FROM app_ticket.ticket_info
WHERE search_doc @@ plainto_tsquery('ngram', '连接超时')
ORDER BY created_at DESC
LIMIT 20;
```

两种写法看起来都能返回结果，但执行路径和扩展能力完全不同。LIKE 更像临时筛选，全文检索才更接近搜索入口。

## 我会特别避开的坑

第一，不把全文检索当成万能模糊匹配。编码、手机号、证件号这类字段更适合精确或前缀查询。

第二，不在查询时反复对大字段 `to_tsvector`。数据量上来后，这会变成稳定的 CPU 消耗点。

第三，不忽略 NULL 字段。多个文本字段拼接时，`coalesce` 能避免很多奇怪结果。

第四，不把权限过滤放到应用层最后做。检索语句里就应该带上租户、部门、状态等条件。

第五，不只追求搜得多。搜得准、排序合理、响应稳定，对业务更重要。

GBase 8c 的全文检索能力对中文和中英混合文本是有价值的。我的感受是，只要业务里已经出现“搜索框”，就应该尽早区分普通筛选和全文检索。继续靠 `%关键字%` 硬扫，短期省事，长期会把性能和体验都拖住。

## 参考资料

```text
GBase 8c 全文检索 https://www.gbase.cn/docs/gbase-8c/05%20SQL%E5%8F%82%E8%80%83/%E5%85%A8%E6%96%87%E6%A3%80%E7%B4%A2
GBase 8c SQL参考指南 https://www.gbase.cn/docs/gbase-8c/05%20SQL%E5%8F%82%E8%80%83/SQL%E8%AF%AD%E6%B3%95
GBase 8c 文档介绍 https://www.gbase.cn/docs/gbase-8c/%E6%AC%A2%E8%BF%8E/
```





GBase 8c

GBase 8c 做中文检索，别只剩 LIKE 在硬扫

GBase 8c 做中文检索，别只剩 LIKE 在硬扫

评论

热门帖子