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

[drymonfidelia]

[Rickkkkkkk]

你确实需要 es

mysql 不是干这个的

[sagaxu]

一亿个字符串 glob ，搞 100 台机器，每台匹配 100 万个就快了

[lmshl]

https://www.postgresql.org/docs/current/pgtrgm.html
你们 mysql 这么拉垮的么

[defaw]

试试 tidb ，ti kv 就适合干这个，唯一的问题是需要很多机器

[changwei]

MySQL 5.6 之后好像支持创建 FULLTEXT 索引，不知道有人试过这个功能没？顺带问问 MySQL 的 FULLTEXT 索引好不好用？

[akira]

我们现在在尝试用 doris 替换掉 ES ，全文检索不知道效果如何

[xausky]

mysql 也有全文索引了，吧 pgsql 的话我们是上 pgtrgm 或者 zhparser 了

[winglight2016]

居然碰到同行了，不过这个需求有点奇怪，物流号都是完整的搜索才有意义，模糊查询有什么用呢？

[drymonfidelia]

@winglight2016 用户懒得输入完整的

[laminux29]

@lmshl 笑死，你发的东西，你都不看一下嘛？

pg_trgm ignores non-word characters (non-alphanumerics) when extracting trigrams from a string.

[laminux29]

这种需求，是没办法用索引的，所以无论什么数据库，包括 ES 、Click House 、Redis 、PG 甚至 Oracle ，都不好使，只能用硬件去硬抗。2 楼老哥说对了。

可以使用基于区域或散列，进行分片，用很多物理机去扛，每台物理机扛一个分片。简单一些可以用 MongoDB ，天生分布式 + 分片。需要高性能那就用 Redis 集群，大内存，数据提前加载到内存里。

话说回来，这种需求，虽然提高了用户体验，但真的烧钱。公司没钱的话，不建议这么做。

[laminux29]

另外，是否考虑修改需求，比如淘宝业务，用户的查询范围只是自己的订单，菜鸟驿站老板查询的范围只是他的驿站范围，那么可以通过剪枝 + 数据冗余的方法，空间换时间，能控制到一个比较理想的性能范围。

然后查询接口，再按时间进行分区：最近 3 个月内是默认查询，如果要查询所有时间范围，就让他们排队查询，或查询结果异步通知。

[Granado]

@drymonfidelia 按你说的，可能是为了方便用户输入，这种是不是应该先构建一个 userid_运单号的索引表，先按用户筛选，再对筛选出的运单号 like

[photon006]

可以试试 starrocks ，语法跟 mysql 兼容，业务代码可能改动很小甚至不需改动

数据分区存，创建表让数据按年份存到不同桶

测试了一张表，dbeaver 显示它有 64G

select count(*) from table
耗时: 1m7s
结果: 16007223598

整张表有 160 亿数据

like 查询过去半年数据，time >= '2024-05-01 00:00:00' and a like '%keyword%' limit 2000 ，耗时 3s 左右

[julyclyde]

你把订单号逆过来存一遍不就得了

[GARLICTRUMP]

只支持查询尾号就行了

[llsquaer]

别 like “%132%”。。 要么前五位 ，要么后 5 位，谁神经病从中间开始。当然不排除特殊情况，订单确实看不清前后几位。这种情况单独处理，让他等。。。

[dragonfsky1]

物流追踪号 这种也可以模糊查询吗？ 这不是就查到比人的了

[lmshl]

@laminux29 笑死, 上网不带脑子

一亿行 pgtrgm 不做分区直接搜, 平均时间也不到 200ms, 要什么集群分片硬件硬扛?
单核 pg, 一年百十块搞定的需求, 照你的方案没个几百万硬件成本怎么玩

[AkaGhost]

如果你换 PostgreSQL 的话，你可以用 TimescaleDB 自动压缩较旧数据