使用思源的过程中,随着文档数量的增多,你有没有发现,有时你的思源无法搜索到指定的关键词?
没错,这不是错觉,这是真实存在的。
那么,原因出在哪呢?
这是因为思源默认的搜索结果只有 64 条,不过,这个条数可以通过设置修改,在设置 》搜索 》搜索结果显示数中可以修改,这里建议修改为 1024 或 2048,可根据自己的实际情况修改,不宜设置过大,过大可能会在搜索时出现卡顿(注意,这个设置同时会影响到 api 的查询结果)。
但,你以为这样修改后就万事大吉了吗?
并不是,你可能还面临搜索不到的情况,原因是思源没有分页。
什么意思?什么是分页?为什么要分页?
假设有这么一个场景,假设数据库有 1 万条记录,但系统最多只允许搜索 500 条结果,如果某个关键词搜索结果是 2000 条,那么无论倒序或正序都无法找到中间的数据,假设用户不记得其他关键词了,只记得这一个关键词,而这个关键词结果是 2000 条,有什么办法让用户能看到中间的结果呢?
没错,就是通过分页显示,每次显示 500 条,一页页查看,就能看到全部数据了。
但,思源的搜索是没有分页的,假设你设置的最大搜索结果显示数是 500 的话,这意味着,你只能看到前面的 500 条(如果正序的话)和后面的 500 条(如果倒序的话)。
那有没有办法查看到中间的 1000 条呢?
比较麻烦,
一,把搜索结果显示数设置的足够大,可以,但不推荐,如果查询条数太多,查询可能会出现卡顿现象。
二,可以通过查询语法,AND OR 等缩小搜索范围,使结果小于 500 条,但前提是必须记得其他关键词或一定不包含的关键词等。
三,可以通过 SQL 查询(没错,思源搜索是支持通过 SQL 查询的,可能有些萌新还不知道),然后通过创建时间或更新时间等缩小查询范围,使搜索结果缩小到 500 条以内,但前提是必须记得文档的大致时间范围,如果不记得了只能通过时间段一点点试了。
但要注意,用创建时间或更新时间可能会出现漏掉或查询到重复数据情况,因为创建时间或更新时间可能相同。如果用 offset 分页,当数据量巨大的情况下,后面的分页数据可能会卡顿。因为思源数据库没有自增的 id,目前没有更好的办法解决这个问题,但如果数据量不是巨大的情况下,只要你的查询不卡顿,建议直接用 offset 分页。
当然,如果你是资深用户,也可以直接通过 sqlite 客户端查询,这个不受思源查询条数的限制,但无法解决数量巨大情况下的分页卡顿问题。
那么,如果极端情况,比如,数据量巨大,SQL 查询卡顿情况下该怎么办呢?
这种情况下,一是建议根据自身情况把空间分割成两个或多个空间,二是建议使用第三方查询工具,比如 everything,然后根据查询结果找到文档 id 后再在思源或 sqlite 客户端中用 SQL 查询。
如果你频繁查询且觉得 everything 不便的话,可以自己搭建全文检索引擎,太过复杂不在本文讨论范围。
总结:
- 搜索结果显示设置,建议设置为 1024 或 2048,也建议官方默认用 1024 或 2048,64 对普通用户太小了,很容易出现搜索不到情况,且萌新们会很懵。 @88250
- 思源搜索中,用查询语法或 sql 缩小搜索范围,但要注意分页问题及时间查询可能出现的漏数据或数据重复问题。
- 第三方 sqlite 客户端 SQL 查询,适合复杂查询,且不想受查询条数限制,数据量适中,不出现分页卡顿的情况。
- 第三方软件查询,比如 everthing,查询到结果后,再在思源中或 sqlite 客户端中用 SQL 搜索,适合极端情况,数据量巨大或 SQL 查询卡顿等场景。
- 其他方案,比如自己搭建全文检索引擎等,太过复杂,不适合普通用户。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于