我个人感觉自从更新了按文档分类搜索后搜索时间增加了很多，目前我搜索一个东西无论是文档内还是全局搜索都是 5 秒左右，但是之前基本都是 1 秒就行，这导致我当初第一时间更新后又回退到旧版本了，旧版本的搜索还是很流畅。这两天发布了 2.5.3 后我又更新试了试但是发现搜索性能还是不行，我不知道是什么原因导致的，试过换成默认主题速度还是慢。跟之前速度对比起来确实相差好几倍。
但是在 2.5.3 我选择不分组搜索后速度还是很慢，我也不清楚是什么原因导致的。
我不知道有没有同样遇到这种问题的。
关于搜索性能问题
-
思源笔记求助问答
3923 引用 • 13694 回帖 • 22 关注
使用思源笔记过程中遇到问题的话请在这里寻求帮助。
相关帖子
-
-
-
abbj •支持者 订阅者
已提供日志。
刚才又仔细观察了一下，我所说的搜索时间长是指从输入完整的关键词到 ctrl+p 界面完整显示内容需要比较长的时间，中间大部分时间页面是空白的转圈状态，所以，不一定是搜索效率低，也可能是显示内容需要的时间长。
1 回复 -
-
zhaoshengmu • • 1 评论订阅者 作者
我虚拟引用是打开的，但是应该不是它的问题，因为在 2.5.0 开虚拟引用搜索速度还是很快，并且我刚才关闭了虚拟引用并且重启了应用但是速度还是很慢，大概平均搜一个要转圈 5 秒，基本不可忍受的时间。systemlog.zip
哦不对，我虚拟引用是一直关着的所以不是它的问题，我刚才说错了我看到设置-搜索中虚拟引用的地方开着我以为自己虚拟引用也开着，忘记前段时间已经关了它了，出现搜索问题前就关了 -
abbj •支持者 订阅者
我虚拟引用一直是开的，跟楼主的感受也差不多，就最近两三个版本开始明显变慢了。前面的版本都还好。我的比计数据量比较大（纯文本 52MB），不知道是否跟这个有关系。
2 回复 -
zhaoshengmu • • 1 评论订阅者 作者
应该也不是，它是一个升级版本后断崖式搜索性能下降的问题，在没有搜索结果分类显示前性能都是好的，我之前一段时间都是回退版本使用的
而且这个也是个例，在我电脑上就是有这个问题但是别的人就没这个问题 -
88250 •订阅者
我这边测试在一个 1G 大小的 siyuan.db 上、data 中 .sy 大小 300M，搜索性能没有太慢，默认使用的是 64 的搜索结果条目限制。
有空的话可以帮忙测试在一个新的工作空间导入这个看看 https://github.com/Zettelkasten-Method/10000-markdown-files
1 回复 -
abbj •支持者 订阅者
我没有导入新的工作空间（还在上班），仅仅是把搜索条目限制还原到 64（原先是 3200），感觉速度有明显改善。
这个设置应该是影响因素之一。
但是为了确保搜索结果没有遗漏，我还是不愿意把这个参数调的太小，不知道是不是还有其他的改进思路？
1 回复 -
-
zhaoshengmu •订阅者 作者
我导入 github 的这个发现搜索速度确实挺快，比我的笔记内容搜索起来快多了，这是什么原因，我的笔记肯定没有导入的这个多。那个搜索结果条目如果设置小了会不会导致有些没被搜索出来？（哦对今天我发现代码语言中没有 vue，typora 中是有的）
1 回复 -
-
abbj •支持者 订阅者
我把思源笔记当做一个法规库来用，目前管理了大概 400 多份法规原文以及差不多体量的我自己整理的笔记，因为有些细节规定很难靠大脑准确记住，工作中有需求的话我都随时用思源来搜索，类似一个本地版的“北大法宝”。所以，搜索结果的完整性对我很重要，我担心那个变量设置太小的话，即使我本地已经有相应的法规，但搜索的时候还是找不到它，所以就随手设置了一个比较大的值，其实到底是 2000 还是 3000，就我目前的数据库来说，应该都不影响结果的完整性。
所以我其实不太能理解设置这个限制的意义（性能影响除外），如果搜索到的结果是不完整的，那笔记的价值不就大打折扣了吗？搜不到的笔记和没有这条笔记感觉没区别。
2 回复 -
-
88250 •订阅者
设置太大的话没有意义吧，比如设置为限制 2K 条，那么这些结果就算命中了也看不完吧。
我举个例子，比如默认设置 64 条，如果整个库中只有 3 条符合条件，那么结果就命中这 3 条，不会出现搜不到的情况，这个条目数设置并不需要超过库中的块数。
-
88250 •订阅者
搜索不到的情况只存在于搜索结果太多时，这时候应该是通过指定排序或者增加搜索条件来缩小搜索范围，而不是让用户在大量的搜索结果中肉眼再去查找，这样就失去搜索的意义了。
从技术上而言是可以通过分页加载解决问题，但是我觉得这是个设计问题，不是技术问题。搜索支持分页加载后会增加用户在搜索上花费的时间。
当然，如果大家觉得有必要这样做，我们会往这个方向考虑一下的，谢谢。
1 回复 -
abbj •支持者 订阅者
我能理解你限制命中条数的思路了。确实是，可以通过优化关键词和添加其他限制条件来提高命中结果的精确程度，但是目前存在两个问题：
1、目前的搜索 ui 不够完善，想达到以上目的只能使用 sql，这个门槛太高了。我日常使用的一些商业化网站（用于搜索法规或者搜索上市公司公告，都是各类纯文本内容），几乎都能做到分别针对标题、内容、发文单位、所在板块、发文时间等多个主题设置不同的关键词，且允许设置多个关键词之间的且和或的关系，还允许设置多个关键词之间是在同句、同段或同篇文字出现，以及明确排除某些关键词（即制定不包含某些关键词）。做的好的，甚至能够就特定事项列出专门的搜索框（例如某事项是否审核通过，因为这类事项不是类似发文单位这种文件中现成且固定出现的内容，通过简单的搜索关键词很难保证结果全面，网站应该是做了专门的工作，感觉属于语义分析范畴）。而思源目前的搜索离我举的例子还有很大差距。
2、即使做到以上程度（或者用 sql），在我的使用场景中，如果程序存在对命中条数的限制，因为没办法准确记得自己想要找到的完整内容，依旧会有搜不到特定内容的可能（我无法判断是我的搜索条件设置不准确导致搜不到，还是我的笔记不包含相关内容，或者是被程序的命中条数限制了所以不显示）。因此，最终还是需要通过比较简单的关键词来显示一个比较大范围的命中结果（确保包含了我目前笔记中的全部相关内容）之后进行肉眼筛选。所以，前段时间上线的分组功能很重要，即使命中结果很多，我也可以依据法规名称快速排除我不需要的项目（这种判断依靠的是我对该法规所覆盖内容的记忆，感觉很难简单的通过各种关键词设置来实现相同的目的）。
所以，在我的使用场景中，优化搜索功能很重要（完善 ui，优化性能），希望 D 大考虑一下，是不是把相关优化工作的优先级提升一下 🙏
1 回复 -
88250 • • 1订阅者
- 通过查询语法，可以解决或且，但是针对字段的搜索条件目前还是只能用 SQL
- 可以通过结果计数判断的，结果计数的计算过程不带条目数限制
最近的版本一直在优化搜索，已经是最高优先级了。但是 SQL 可视化的特性暂时还没有计划，估计要等 2.6 完成间隔复习以后我们再排计划是先做这个还是先做白板，可能会发起社区投票收集建议，谢谢。
1 回复 -
abbj •支持者 订阅者
感觉 276 的搜索速度比 274 有很大提升，同一个工作空间，我依旧设置搜索结果显示数量是 3200，ctrl+p 显示结果的速度显著快于以前的版本，是 276 在这方面做了改进吗？
1 回复 -
-
请输入回帖内容
...
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于