如何低成本解决模糊搜索问题

[brader]

用的 mysql 数据库，有时候做业务，动不动产品就会说，这个字段我要模糊搜索。 实在不想大费周章，直接用的 like ，前期还好，到了后面跑不动，还有没有其他低成本的替代方案？

[sadfQED2]

5.6 5.7 的 mysql ，不用 es ，不用 like ，那你手动拆词，然后在 mysql 里面建一张表当倒排索引？相当于用 mysql 实现一个简易版的 es

不然的话就找那些奇奇怪怪的 mysql 插件或者存储引擎？但是这种稳定性就不敢保证了

最后，人和代码有一个能跑就行，没有需求评审，也没有技术评审，上线时间拍脑袋决定，我觉得该你跑了

[Latin]

上个 elasticsearch 解君忧

[3kkkk]

如果没用过，上面哪种方案用到生产都不是几个小时搞定的。 让产品需求做技术调研，不给时间就让他们自己搞你把上面方案给罗列了。

[Buges]

当然是 meilisearch ，简单轻量，适合小规模数据。

[clf]

搜索的时候加上数据量限制？不返回有多少条符合结果的 total 。

前缀搜索的效率会高很多，能走索引。

[documentzhangx66]

模糊搜索本来就是个成本高上天的事情，其成本比分词方案还要高，所以你这出发点就不对。

你只能采用 有限度的分词 + 主动缓存 + 控制频次的方式，来降低成本，这种思路类似于剪枝，但仍然有一定成本。

[zamaojava]

不直接 run 吗，兄弟，我上家就是给我 精确 crud ，老子直接不干了

[monkeyWie]

上 es 分词也难搞定，例如搜索一个字的时候

[nox42]

lucene

[yufeng0681]

产品要快速出效果，3 小时的编码， 就只能用 like ，解决业务功能有无的问题；
和项目经理说，后续肯定有性能问题，要解决就得技术 leader 上方案，给你们写业务代码的人用，或者单独给时间做这个性能需求。
至于做不做，那就是项目经理决定。

[makdon]

看起来开发地位非常工具人呐，代码跟人有一个能跑就行

[westoy]

跑不动再说吧, like 至少能找到啊.....你分词+fulltext 调教不好， 很多词分错了找都找不到， 更麻烦.......

[marcojbk]

我其实有点没明白你说到了后面跑不动是什么意思，是说查询速度太慢，还是说无法实现比如多词中间加空格搜索的需求？

[brader]

@wellerman 没有词意概念的，他们不需要分词效果，只要 like 那种模糊效果

[brader]

@zamaojava 今年跑不了，有购房计划，跑也要过了今年

[brader]

@marcojbk 用 Like 功能是完全对的，就是数据量多起来了，查询非常慢，我记得那个表，涨到 50 万，就不怎么查的动了

[meystack]

直接上 ES 或者迅搜，我有写好的类，在我开源的项目 swiftadmin 你在 fork 里面找下之前的备份，可以分分钟使用了，如不是很复杂，建议使用迅搜即可

[tickone]

可以试试这样查，扫描 name 索引，不是全表扫描，稍微好一点
select * from table where id in (
select id from table where name like '%哈哈%'
)

[markgor]

这情况，不是应该转移问题吗...?
前端增加 “等于”/“包含” 让用户选择，当使用包含慢的时候，说这是特性，嫌慢就用等于来筛选；或者搭建 ES 服务....
让产品自己选择

[lizy0329]

@teel 后端弄个缓存，前端一拉就拉 1w 条数据，应该可以吧