最近项目需要全文检索，所以找了几个开源的.NET检索项目，如：Lucene.net，Sphinx，Hubble.net。最后选择使用Lucene.ne来实现全文检索。至于原因嘛，可以参考下面几点：
1) Sphinx性能非常好，而且和Mysql结合的也非常好，但是，我们目前使用的是SqlServer，这个优势我们也就用不着了，关键问题在于，Sphinx需要把整个索引吃到内存中，当索引比较大时，内存会不够，关键是这个问题没有找到合适的解决方案，最后只能舍弃。
2) Hubble.net的性能也很好，而且和SqlServer结合的非常好，所以，打算使用Hubble.net，使用时发现，Hubble.net只有在查全文时，才会使用Hubble.net自身检索引擎。如果要查一些整形或时间或关键词精确匹配时，就必须通过SqlServer的检索来实现。听说作者已经有意要把整形或时间等其它类型数据放入Hubble.net来进行检索。目前只能期待。。。。
3) Lucene.net，这是目前使用的检索项目。Lucene.net在性能方面可能不如上面两种，但是性能至少能满足我们目前的需求，而且有灵活的检索方式，强大的社区支持，丰富的资料说明，这是我决定使用Lucene.net项目的原因。
如果我介绍的Sphinx和Hubble.net项目的缺陷已经解决或有解决方式，请高手们不吝赐教，谢谢。
测试服务器为HP服务器，Windows08系统，12核CPU，16G内存。
软件架构使用.Net4.0+Sqlserver08+Lucene.net3.0+盘古分词。
数据量约2300万，索引30G。
测试方式：单个索引（30G）性能测试、多个索引（每个索引10G，共3个索引）性能测试、多个索引（每个索引10G，共3个索引）并行检索性能测试。
备注：单个索引通过类IndexSearcher实现。
多索引检索通过类MultiSearcher实现。
多索引并行检索通过ParallelMultiSearcher实现。
测试结果：
单个线程下，连续检索25次，取平均值。（不同的关键词，避免Lucene.net的缓存）。
|
单索引 |
多索引 |
多索引并行 |
|
408毫秒 |
420毫秒 |
230毫秒 |
多个线程（15个），连续检索25次，取平均值。（不同的关键词，避免Lucene.net的缓存）。
|
单索引 |
多索引 |
多索引并行 |
|
1.15秒 |
1秒 |
900毫秒 |
如果线程再多，CPU就会超100%，所以，检索对CPU要求很高，要适应并发，就一定要用缓存。结果显示，多索引并行的效率是最高的，也是最耗CPU的。
下面是我用Lucene.net做个一个例子。如何做索引以及检索的实现，都在源代码中。有兴趣的朋友可以一起看看，如果有好的想法，可以一直讨论商量。下面是检索截图，本人不擅长做前台，页面比较丑，见谅。
总结：
使用Lucene.Net时，在功能与性能方面，谈一下个人体会，仅是个人的体会 。
1) Lucene.net在检索时，是很耗CPU的，但是，吃内存很少（当然不使用内存模式）。
2) Lucene.net在多索引并行检索时，效果比单索引更好，建议使用。
3) IndexSearcher对象打开一次就行，不要频繁打开，很耗时间。
4) 如果要实时索引，建议直接追加索引，不要合并（很耗时），等有空闲的时间，再进行合并，追加后的记录是检索不到的，需要重新打开IndexSearcher。重新打开IndexSearcher很耗时间，所以根据需要去决定何时去重新打开IndexSearcher。
5) Lucene.net在检索关键词时，如果关键词太长，速度是非常慢的，因为分词后，要检索的词太多，建议分词后，把无用的单个字过滤掉，因为单个字的检索意义不大，而且，很耗时间。如：我们在希望的田野上。分词后为：我们/在/希望/的/田野/上。其中，“在/的”的意义并不大，建议过滤掉，可提高性能。
6) 听说使用固态硬盘可直接提高检索速度，由于本人没有固态硬盘，所以，这里无法给出测试结果，有测试过的朋友，可以讲讲。
7) 如果单台服务器无法满足检索需求时，就必须要分布式了，可采用Lucene.net+Wcp+缓存服务器来解决。WCP来做通信，Lucene做检索，中央服务器向各检索服务器发送请求，然后实现各个检索服务器结果集的合并，缓存服务器来解决大并发的问题。这个方案我目前还没有测试过，只是一个想法。等日后验证完，再与各位朋友交流。
感谢盘古作者eaglet提拱了.NET的分词系统
感谢宝玉解决盘古在Lucene.net3.0中无法使用的问题。