首先，全文检索对你这个问题的效率也很低，因为订单号你怎么分词？全文检索是建立在分词然后倒排索引的基础上的，你这是需要对十几位订单号，就按 18 位好了，你知道 18 位全组合的组合模式有多少种么？无脑说上全文检索的，先搞清楚全文检索原理先啊。 相比起来 22 楼 @lmshl 的方案更具备工程上的可行性。
@drymonfidelia #9 不能既要又要还要啊，哪有懒得输入这种需求的，最多给他提供复制粘贴、图片识别、bar 枪扫码这些工具 另外，ES 并不能解决模糊查询的问题，ES 的反向索引是基于分词去做的，连续的字母数字会被分为一个词，没法提前建立索引。 归根结底，不定长模糊查询查出来的数量无法提前预估，超过 100 条了，必然需要分页，那这个功能对于用户来说毫无意义。
不确定的检索，推荐 starrocks, ClickHouse 等列数据库，暴力检索，适当的分片，在没有索引的情况下，列数据库比行数据库好多了，你说归档数据就更加适合了，基本上都是数仓的场景，数仓会稍微慢一点点，这个数据量毫秒级。 假如要非常快的查询，可以说服产品，允许少概率查不中的场景，es 分词一般情况下能够命中，某些场景下，会检索不到，它毕竟不是模糊检索。 事实上全世界都没有解决低延迟的海量数据的模糊匹配，快和模糊查询是不可能并存的。
ClickHouse 吧， 你这亿级对它来说都不够看，估计单机都能做到秒级查询 数据比你大一个数量级的，多字段模糊查询 + 统计聚合出报表，分片后也能坐到秒级 ES 很多年我也用过，也是亿级数据（甚至也是查单号），很折腾，除非你能保证一辈子不重建索引，重建一次就半条命 但，我不确定你是不是真的需要这些东西，在企业里这些成本都挺高的 如果你只是单字段有模糊查询的需求的话，pg 都足够应付了，楼上也有兄弟提到了 只有查询没有聚合需求的话，你还可以极端一点，搞一张表两字段，专门用来查询
