在我们的应用程序中，我们一直在使用Lucene.Net来索引大量数据。字段本身是可配置的，因此字段的名称和类型可以随着每次重建而改变。在每个文档中，我们可以有多个具有相同名称的字段以及不同数量的数字和文本字段。由于我们在当前开发中投入了大量工作，因此更改为不同的搜索引擎是不可能的。
事实是，在很大程度上，它是一种魅力，但我们确实有一个困难，我们似乎无法解决。
假设我们要索引文档“X”，其中包含：
A行-字段1:4字段2：a
B行-字段1:8字段2：b
我们将创建的索引将包含4个字段：
（行ID不重要）
搜索Field1：[3 TO 6]AND Field2： b会命中此文档。
但是，行表示的字段之间的链接（链接4和'a'）消失了。
我们可以像4_a一样连接值，但这会破坏我们的数字搜索，并要求客户端知道哪些字段被连接以获得正确的结果。这也会增加我们分析器的难度，因为对于每个字段，我们可以添加不同的分析器（主要用于语言目的）。
此外，我们可以使用相同的键为每一行创建一个单独的文档，并在搜索结果中添加一个不同的文档，但这听起来不像是要走的路，不是吗？它会严重增加文档的数量，因为我们现在将为每个文档创建20-100个文档。我还没有在性能或可用性上测试过这个，因为当前的实现不允许我很容易地尝试这个：-）
有没有人知道我如何在Lucene.Net中强制某些字段之间建立链接，但仍然保持单独搜索每个字段的方法？
我个人不明白为什么增加文档数量会影响性能。至少在Java版本的Lucene中，大部分内存用于术语缓存——这是每个术语的，与文档计数没有关系（前提是术语计数不会改变）。不能详细说明可用性，因为这是特定于您的应用程序的。
要点是，一旦你将行分组到文档中，你就会丢失行关系信息。你可以通过添加额外的字段来解决这个问题（比如rowInfoA：4_a，rowInfoB：8_b），但是这看起来太麻烦了，实际上需要更多的内存。是的，你可以选择不索引，只存储这些辅助字段，但是我（已经给出了信息）仍然更喜欢1:1的行：文档映射。
一个小程序是为联系添加另一个字段：
>
文档X：
另一个麻烦是添加一个字段，如MyDocument： X并单独索引每一行，每一行都包含一个MyDocument字段作为其Document。这将使您可以在以后的过程中按文档过滤。
