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

[drymonfidelia]

[ferock]

是客户的需求还是领导的需求？

[lmshl]

如果是物流追踪号这种定长且总长度不长的短字符串, 直接把每个截断前缀都做一遍索引还更简单, 也能支持精确匹配.
tracking_number[0:16]
tracking_number[1:16]
tracking_number[2:16]
tracking_number[3:16]
...
tracking_number[13:16]
都做成表达式索引, 查询的时候只需要 LIKE ‘123%’, 一样可以做的很快

[rrfeng]

es 对这个问题毫无帮助。

[kk2syc]

把数据库挂公网上，过一阵子就有秒查的可以用了 /doge/doge

[levelworm]

能不能用时间来切啊？总不至于全表查询？用户最多也就一个礼拜之外吧。。。

[laminux29]

@lmshl

如果你看不懂 10 楼发的英文，可以试试翻译软件。

[xuanbg]

@drymonfidelia OP 你这个就是伪需求。首先，这个查物流单号是随便查的还是只能查自己的？如果是随便查的，那就必须要精确，不然，你查到别人的物流信息算怎么回事？如果是只能查自己的，那条件就不是只有 like 了，先根据用户 id 查，在几十最多几百个结果中 like ，根本不影响什么。

[mayli]

@drymonfidelia 前缀后缀 ngram

[spiffing]

应该想办法优化一下需求。
我们也有订单匹配物流的查询，前提是订单信息查出来才继续给显示物流的部分。

[wssy001]

@sagaxu 只顾着优化单条数据查询却不考虑报表聚合查询是吧？

[skinny]

@laminux29 虽然但是，难道物流追踪号不是只包含字母数字吗？！

[yuxian]

用 ES 吧，毕竟是标配。一次部署，后面梭哈。资源不够加机器，加节点。成本？等你的价值有机器贵了再说。可以早点下班的事儿，为何不干呢？我用 es 处理百亿级别的数据，都很轻松。什么垃圾都可以往里面丢。
ES 有优秀的生态，出问题了，都可以找到相应的解决方案。有专业人在维护。你只是用 ES 做索引而已。又不用担心数据丢失问题。
如果再想加速，套个 redis 也不是不行，对于常常用到的缓存一下。基本上 99.99%都是冷数据。
关系型数据库，已经用 mysql 了，没有必要用 pgdb 。本质上没有太大区别。

[isnullstring]

物流号不应该是%%查询呀

想清楚 这个需求是不是对的，是不是硬性要求再考虑怎么做

[sagaxu]

@lmshl 19#

1. 订单号不是随机数，部分匹配区分度低，比如 2023 匹配出来就是 2023 年全年订单。
2. pg_trgm 是匹配出相似度大于阈值的条目，跟 is_substring 逻辑不同，有假阳性。
3. 切分单号改成 like 'xxx%'匹配，索引规模放大十几倍，且解决不了'%a??b%'这种。

[iseki]

@laminux29 non-word 是指空白符什么的，数字属于 word ，虽然我也不知道这是哪里的规定

[iseki]

@sagaxu pg 一般这种场景直接用 like ，系统会自动加一个 recheck 解决假阳性

[tairan2006]

伪需求把，模糊查询岂不是信息泄露了……

[godwinma]

@Granado 这个思路很合理

[ala2008]

不应该先查询出 id ，再去匹配吗

[cexll]

其实没有必要争论楼主是不是伪需求，菜鸟不就是这样吗？ 根据运单尾号 之类的 查询在当前站点的快递单号，当然前提肯定是 WHERE + WHERE 你在亿级里面全量查询 必然不合理