我一直在使用postgresql进行全文搜索，将文章列表与包含特定单词的文档进行匹配。性能随着行数的增加而降低。我一直在使用postgresql支持全文搜索，这使性能更快，但随着时间的推移，随着文章的增加，搜索速度会变慢。
我刚刚开始用solr实现搜索。通过浏览网络上的各种资源，我发现它可以做的不仅仅是搜索，还可以让我更好地控制我的结果。
Solr似乎使用了inverted index，如果许多文档（超过100万）包含用户开始查询的搜索词，的性能不会随着时间的推移而降低吗？此外，如果我在计算文档的score时，通过对搜索词进行分页来限制结果，难道不需要先加载所有100多万个文档，然后限制结果，因为许多文档都有相同的单词，这会降低性能吗？
是否有一种方法可以首先根据分数本身对索引进行排序，从而避免以后加载文档？
Lucene的设计目的是解决您提到的所有问题。除了反向索引，还有发布列表、文档值、索引值和存储值的分离等等
然后你有Solr在上面添加更多的好东西。
对于Lucene/Solr来说，100万个文档是一个入门级的问题。它正在维基百科转储索引中进行例行测试。
如果你觉得你真的需要了解它是如何工作的，而不仅仅是让放心，请查看Lucene上的书籍，包括旧的书籍。还要查看Lucene Javadocs——它们通常有额外的信息。