亿级订单表 要对物流追踪号支持 LIKE %123% 这样的前后缀都模糊查询，现在的 MySQL 查一次要几分钟，必须上 ES 或者 ClickHouse 吗？另外归档数据也要查，有没有办法压缩存储数据

@iseki
你这个例子，假阴性不就出来了：

4 、5 、
1234 、12345 、
2 、23 、2345 、
3 、34 、
4 、
5

这些都缺失。

@laminux29 …你要不自己下载个 pg 试一下
我这个例子只是告诉你 k-gram 是个啥东西，不是说 pg 只会从这几个值里挑一个去找索引。

@dejavuwind 对的，similarity 就是明确的模糊查询，这个 case 显然要求的是精确查询

@laminux29 pg 的实际做法，可以看做（我没读代码，只说等效结果），按 3gram 输出的所有条目去查 gin 索引，对结果 recheck 。这种做法不可能出现漏掉数据的情况。

@julyclyde 我们是这样做的哈哈哈哈

问题不是一个。
1. like 优化的问题，上 ngram 分词索引，限制最短 like 字符串长度，n 越大效果越好，能效很强，n=4 情况下索引大概是 5 倍存储
楼上有 pgtrgm ，这个也是种 ngram 分词索引。
#86 说分词无法解决这种精确问题的，ngram 这种暴力分词手段专门破这种局面，

至于，ocr 的结果要模糊，记得一点，like 不是搜索，搜索要多关键词权重匹配，上 es 最简单

2. 归档数据也要查，这个自己业务上区分查询口，长期的数据归档到列存，clickhouse/doris/hive/iceberg 都行，主要是查询引擎用啥。至于速度，看表设计
哪怕用列存，like 这种场景，该上 ngram 也是要分的，无索引速度上不来必须要成为基础认知