我已阅读( http://old.nabble.com/using-q%3D--,-adding-fq%3D-to26753938.html#a26805204 ):
FWIW: limiting the number of rows per request to 50, but not limiting the start doesn't make much sense -- the same amount of work is needed to handle start=0&rows=5050 and start=5000&rows=50.
比他完成:
There are very few use cases for allowing people to iterate through all the rows that also require sorting.
是吗？仅对于排序结果来说是这样吗？
您建议使用多少页(每页 10 行)来允许用户进行迭代？
Solr 1.4 是否也存在同样的限制？
最佳答案
是的，对于 Solr 1.4 也是如此。这并不意味着 start=0&rows=5050 与 start=5000&rows=50 具有相同的性能，因为前者必须返回 5050 个文档而后者只有 50。传输的数据更少 -> 更快。
Solr 没有任何方法可以在单个页面中获取所有结果，因为它没有多大意义。相比之下，您无法在单个查询中获取整个 Google 索引。没有人真的需要这样做。
应用程序的页面大小应该是用户可定义的(即用户可以选择一次查看 10、25、50 或 100 个结果)。
默认页面大小取决于您分页的数据类型以及结果的实际相关程度。例如，在 Google 上搜索时，您通常不会超出前几个结果，因此 10 个元素就足够了。另一方面，eBay 更多的是浏览结果，因此默认情况下每页显示 50 个结果，甚至每页不提供 10 个结果。
您还必须考虑滚动。用户在尝试浏览200-result page时可能会迷失方向。 ，更不用说加载时间要长得多。
关于java - Solr分页性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2123778/