Improve search group by doc

[QMike0]

全局搜索设置按文档分组，同一文档会被分成多次显示

Is there an existing issue for this?

• [X] I have searched the existing issues

Can the issue be reproduced with the default theme (daylight/midnight)?

• [X] I was able to reproduce the issue with the default theme

Could the issue be due to extensions?

• [X] I've ruled out the possibility that the extension is causing the problem.

Describe the problem

在全局搜索设置按文档分组后，同一文档会被分成多次显示，每次显示所包含的内容块不同，这些内容块加在一起才是该文档中包含相应关键词的全部内容。该问题可能只出现在搜索结果较多的情况。我对全局搜索的筛选设置如下：

以我笔记中的文档《GNSS&INS组合导航》为例，搜索关键词导航，该文档会出现多次，如下（多图警告）：

Expected result

全局搜索设置按文档分组后，同一文档的内容块应集中展示在同一文档下（顾名思义嘛），而不应该分开 仍然以《GNSS&INS组合导航》为例，里面共有16个内容块涉及到关键词导航，那么在搜索导航时，应按照如下进行集中展示：

Screenshot or screen recording presentation

No response

Version environment

- Version: v3.0.17
- Operating System: windows11
- Browser (if used):

Log file

system-log.zip

More information

No response

[88250]

完全不分页查询的话数据量大了会非常慢，改为按 设置 - 搜索 - 搜索结果显示数 限制吧。

[mozhux]

完全不分页查询的话数据量大了会非常慢，改为按 设置 - 搜索 - 搜索结果显示数 限制吧。

前天处理了一个咨询问题。。说是搜索少很多结果，很多人没看到上面的分页按钮，而且以为滚动和方向键下会动态加载新的。。 我建议还是滚动下来能动态加载分页吧。

[88250]

还是用分页吧。

[QMike0]

完全不分页查询的话数据量大了会非常慢，改为按 设置 - 搜索 - 搜索结果显示数 限制吧。

前天处理了一个咨询问题。。说是搜索少很多结果，很多人没看到上面的分页按钮，而且以为滚动和方向键下会动态加载新的。。 我建议还是滚动下来能动态加载分页吧。

+1，我也是最近用搜索功能的时候总感觉少很多内容才提的这个issue。分页展示确实可以避免性能问题，但会导致误解是搜索结果不全，特别在按文档分组的情况下分散到不同页面更像是一种bug

[88250]

这应该是个使用习惯问题，可能需要强调一下分页？

[QMike0]

这应该是个使用习惯问题，可能需要强调一下分页？

胖佬说的动态加载是一种思路；如果继续分页展示的话，也可以在当前页滚动到底部的时候，显示类似于下面的页面选择，取代现在的把分页按钮放在左上角，应该会更直观一些

[QMike0]

另外，按文档分组最好还是能放一起，即使分页展示，下一页的内容和上一页的内容应该接上，这样比较符合正常查找逻辑。 比如上面图中的GNSS&INS组合导航文档，即使同一页无法完全展示它里面的内容块内容，下一页的开头也应该继续展示GNSS&INS组合导航文档对应的内容块

[88250]

这应该是个使用习惯问题，可能需要强调一下分页？

胖佬说的动态加载是一种思路；如果继续分页展示的话，也可以在当前页滚动到底部的时候，显示类似于下面的页面选择，取代现在的把分页按钮放在左上角，应该会更直观一些

新开个 issue 展示分页信息 https://github.com/siyuan-note/siyuan/issues/11699

[88250]

另外，按文档分组最好还是能放一起，即使分页展示，下一页的内容和上一页的内容应该接上，这样比较符合正常查找逻辑。 比如上面图中的GNSS&INS组合导航文档，即使同一页无法完全展示它里面的内容块内容，下一页的开头也应该继续展示GNSS&INS组合导航文档对应的内容块

有道理，稍后看看能否优化。

[88250]

尝试了下，文档分组分页后的排序没有办法保证切换分页时文档的顺序不变，因为是按照 blocks 搜索分页的，其结果在聚合分组，所以后面的页中可能会包含第一页结果之外的文档从而打乱第一页中看到的文档顺序。

[QMike0]

尝试了下，文档分组分页后的排序没有办法保证切换分页时文档的顺序不变，因为是按照 blocks 搜索分页的，其结果在聚合分组，所以后面的页中可能会包含第一页结果之外的文档从而打乱第一页中看到的文档顺序。

能否按文档分组的搜索结果不直接展示各个内容块，而是按照搜索结果显示数只展示限制数目下的文档（折叠状态），展开该文档查看时再动态加载它包含的内容块。这样应该能最大程度避免性能问题，也能避免分页导致的混乱

[88250]

这样的话还是可能碰到两个问题：

• 文档中命中的块太多，展开加载还是有性能问题
• 每次都需要展开，使用起来较为繁琐

[QMike0]

每次都需要展开，使用起来较为繁琐

个人来说，每次都需要展开虽然有点麻烦，但相较于同一文档的搜索结果分散在不同页中、导致的搜索结果不全的错觉，其实更能接受前者。「全但麻烦」比「简单但乱」要更有安全感，并且更能体现按文档分组这个概念一些

文档中命中的块太多，展开加载还是有性能问题

这个方案其实插件「基于文档搜索」现在在用，实测性能影响不大，例如下面这些包含三百多搜索结果的文档，展开加载是很顺滑的。也有可能作者是做了优化

[88250]

上面这个截图中右边的结果计数应该不是展开的时候才计算的吧？如果不是的话其实也做了一次不分页的全库搜索，你那里测试如果觉得不算慢的话那我们也可以试试不分页。

干脆这样吧，这个 issue 先按不分页（即将分页大小设置为整数最大值）实现，后续如果有人反馈性能问题，我们再考虑回退到按 搜索结果显示数 进行分页限制。

[QMike0]

上面这个截图中右边的结果计数应该不是展开的时候才计算的吧？如果不是的话其实也做了一次不分页的全库搜索，你那里测试如果觉得不算慢的话那我们也可以试试不分页。

对，是折叠状态下显示的。不过它限制了每页的文档数量，每页在切换时会有短暂的加载过程。很短，即使像我截图里面所示文档包含1000多搜索结果，每页加载时间也不到一秒。

这样来看可能并非做的是完全不分页的全库搜索，只不过分页并不是思源这种基于内容块数量这种形式，而是每页展示的文档页。如果完全不分页的话，我估计肯定会有性能问题的反馈😂

[88250]

你整个库有多少块，可以看下启动后的日志。

[QMike0]

你整个库有多少块，可以看下启动后的日志。

system-log.zip 这个嘛？不知道怎么看😂

我用wordcount挂件的统计结果是这个（不过好像不太准）：

[88250]

tree/block count [534/53733] 这个数量下性能问题不大，但是几十万的块可能就会比较慢了。

算了，这个 issue 暂时还是不做了，目前没有充分测试的条件，为了保险起见，还是撤销提交吧。等后面有机会我们再重新考虑。