使用Solr的rows与start参数实现分页时是否需要排序？

Great question—this is a super common pitfall when working with Solr's start/rows pagination, so let’s break it down clearly.

1. Is sorting mandatory when using start/rows? #

Strictly speaking, no—Solr doesn’t force you to specify a sort parameter. But here’s the critical catch:

• By default, Solr sorts results by relevance score (score) in descending order.
• When multiple documents have the same score (which is extremely common in many use cases), their relative order is not guaranteed. This is because Lucene’s internal document IDs can shift due to index updates, segment merges, or even distributed query behavior (if you’re using a SolrCloud cluster).

So while it’s not technically required, explicitly defining a stable sort order is non-negotiable for reliable pagination. Without it, you risk inconsistent result sets across page requests.

2. Can duplicate results occur between page requests? #

Absolutely—this is exactly what happens when you don’t have a stable sort. Let’s use your 30-record example:
Suppose 10 of those records have the exact same relevance score. When you first query start=0&rows=5, Solr might return documents A, B, C, D, E (all with the same score) as the first 5. On your next query start=5&rows=5, due to subtle changes in index state or query execution, the order of those 10 documents could shift—so you might get E, F, G, H, I instead of F, G, H, I, J. Now document E appears in both pages, and J is missing entirely.

This inconsistency gets worse in SolrCloud, where results from multiple shards are merged; without a stable tiebreaker, the merged order can vary between requests.

How to fix this? #

The solution is to add a unique, deterministic tiebreaker to your sort parameter. This ensures that even if scores are equal, the order of documents remains fixed across all queries. Examples:

• If you want to prioritize relevance first: sort=score desc, id asc (use your unique document ID as the tiebreaker)
• If you prefer a business-specific order: sort=created_at desc, id asc (sort by a timestamp, then ID)

By including a unique field (like id) as the final sort condition, you guarantee that every document has a fixed position in the result set, eliminating pagination duplicates or missing records.

内容的提问来源于stack exchange，提问作者Rachit