Indexing 为什么向我的Clickhouse表添加tokenbf_v2索引没有任何效果

我在Clickhouse中有一个很大的表，其中有一列名为“Route”，它是一个以逗号分隔的id字符串。它看起来像这样：12342125245346263。一个字符串中可以有数百个id

查询该表以选择通过订单重要的特定id的路线，如下所示：

SELECT * FROM MY_TABLE WHERE Route LIKE '%123421%346263%'

由于查询可能非常慢，我尝试通过在Route列上添加一个数据跳过索引来加快查询速度。根据Clickhouse文档，tokenbf_v2索引似乎是为我的目的而创建的，因为据我所知，它应该将我的Route列分解为令牌，并且应该有助于加快查询速度

但是，当我添加带有以下内容的索引时：

alter table MY_TABLE add INDEX route_index (Route) TYPE tokenbf_v1(256, 5, 0) GRANULARITY 1;

，并确保它是通过运行

OPTIMIZE TABLE MY_TABLE FINAL;

根本没有提速

当我在clickhouse client中分析我的查询跟踪时，它始终显示：

Index `route_index` has dropped 0 granules.

显然，我的BF指数没有任何影响。有人不知道为什么吗

---

顺便说一下，我的路由列具有类型字符串，表my_table的粒度为128。

为了保证将索引应用于所有数据，需要将它们全部重新插入。我建议使用所需的索引创建测试表，并部分填充它。将其用作寻找更多最佳索引的游乐场

考虑使用hasToken函数或允许使用tokenbf_v1-index的其他函数，请参见：

挑选* 从…起 选择* 从我的桌子上 其中hasTokenRoute'123421'和hasTokenRoute'346263' 其中的路由类似于“%123421346263%” 就像你真的能工作一样

---

谢谢你的回答！您对hasToken的建议是正确的，这将导致notkenbf索引：索引route_索引下降了254959个颗粒。但是，bloomfilter并没有加快我的查询速度，而是实际上减慢了我的查询速度！从MY_表中选择Count，其中hasTokenRoute“346263”需要10秒，但从MY_表中选择Count，其中类似“%346263%”的路由需要6秒，即使这不使用索引！根据查询跟踪，ntokenbf索引正在删除大多数行。但出于某种原因，它还是会扫描表中的所有行。。。

select Count(*) from MY_TABLE where Route like '%,3119550599,%'
Index `route_index` has dropped 781655 / 782032 granules.