@webeasymail #19 把数据库里的所有 title 和 Company 的数据 变成索引，搜索时候就能联想出来。能联想到的就优先查（详细描述不用 like ，因为肯定命中了。 其他条目的详情里面如果有同样的 key ，也不建议显示出来，这个其实是相关竞品数据） 如果没有联想到，那就 三个字段都 like ，慢一点就慢一点，说明用户本身也没记住名字，大概率是记错了产品名字。 新场景：用户关注某个领域的产品，希望按类索骥走马观花，所以：层级分类确实要做好
- pg 原生 FTS： https://pigsty.cc/zh/blog/dev/fuzzymatch/ - pg 扩展 paradedb： https://pigsty.cc/zh/blog/pg/paradedb/
最轻量简单的，应该是 1MB 的 SQLite 了吧。。 案例就是手机端上的微信，全文搜索了吧。。 [《微信全文搜索耗时降 94%？我们用了这种方案》]( https://cloud.tencent.com/developer/article/2220615 ) 里说： > 一个包含 100w 条中文内容、每条长度 100 汉字的 FTS5 的表查询三个词，optimize 状态下耗时 2.9ms > 100w 条内容每次写入 100 条的情况下，按照 WCDB 的方案执行 merge ，耗时在 10s 内。
