我们有一个SQL Server数据库，其中包含由Lucene.net到Nhibernate.Search编制索引的百万条记录。当我们为我们的类构建索引时，我们试图扩展，因为索引/检索的成本非常小。我们的目标是在分页的网页上为用户提供全文搜索。
由于SQL Server在向它发送太多参数时会抱怨（默认情况下为2100个参数），并且因为我们每次达到限制时都不想更改该参数（这很容易发生，我们文档中的某些术语非常有用）常见但必须是可搜索的）我们决定处理从Lucene的排序到分页的所有内容。它就像一个魅力。
但是，最近，feature-creep导致了一些问题，因为新查询不仅需要访问未编制索引的字段，还需要访问不应访问或无法访问的字段：计算字段，推荐清单等 ......
由于我们已将所有分页和排序放在Lucene.Net中，并且由于SQL Server对其参数很挑剔，我们如何才能设置好蛋糕并吃掉它？
我正在考虑首先进行sql查询计算，将元素减少到他们的doc id然后给Lucene提供一个巨大的OR查询以及所有可能的id，让它正确选择可能的东西，但我担心查询大小< / p>
伪代码
listIds = Nhibernate.Criteria.ReduceToIds.List(of MyObject)
queryIds = String.join(" ID:", l)
return NHibernate.Search(queryIds)
显然，Lucene Filters可以通过只允许某些文档ID作为查询的一部分来工作，所以它应该是可能的，但我真的没有办法在Nhibernate.search中做到这一点
你知道我应该如何处理这个问题吗？是否可以通过向SQL询问ID列表来过滤查询？这有点矫枉过正吗？还有其他任何解决方案吗？
答案 0 :(得分：1)
当Lucene.Net返回超过2100个结果时，通常会遇到问题，因为NHibernate.Search将构建一个大的SELECT * FROM T WHERE ID IN（@ p0，@ p1 ...）
因此，如果您的lucene查询返回的结果不超过2100，那么您应该没问题。