我不了解Sphinx，但是对于Lucene和数据库全文搜索，我认为Lucene的性能是无与伦比的。只要你正确地设置了Lucene索引，无论你要搜索多少条记录，你都应该能够在10毫秒内完成几乎所有的搜索。

最大的障碍来了:就我个人而言，我认为在你的项目中集成Lucene并不容易。当然，设置它并不难，这样你就可以做一些基本的搜索，但如果你想充分利用它，获得最佳性能，那么你绝对需要一本关于Lucene的好书。

至于CPU和内存的需求，在Lucene中执行搜索并不会给CPU带来太多的任务，尽管索引你的数据是，尽管你不经常这样做(可能一天一次或两次)，所以这不是一个很大的障碍。

它不能回答你所有的问题，但简而言之，如果你有大量的数据要搜索，并且你想要出色的性能，那么我认为Lucene绝对是一条出路。如果你没有那么多的数据要搜索，那么你也可以使用数据库全文搜索。在我的书中，设置MySQL全文搜索绝对更容易。

很高兴看到有人插话谈论Lucene——因为我对此一无所知。

而斯芬克斯，我很了解，所以看看我能不能帮上忙。

Result relevance ranking is the default. You can set up your own sorting should you wish, and give specific fields higher weightings. Indexing speed is super-fast, because it talks directly to the database. Any slowness will come from complex SQL queries and un-indexed foreign keys and other such problems. I've never noticed any slowness in searching either. I'm a Rails guy, so I've no idea how easy it is to implement with Django. There is a Python API that comes with the Sphinx source though. The search service daemon (searchd) is pretty low on memory usage - and you can set limits on how much memory the indexer process uses too. Scalability is where my knowledge is more sketchy - but it's easy enough to copy index files to multiple machines and run several searchd daemons. The general impression I get from others though is that it's pretty damn good under high load, so scaling it out across multiple machines isn't something that needs to be dealt with. There's no support for 'did-you-mean', etc - although these can be done with other tools easily enough. Sphinx does stem words though using dictionaries, so 'driving' and 'drive' (for example) would be considered the same in searches. Sphinx doesn't allow partial index updates for field data though. The common approach to this is to maintain a delta index with all the recent changes, and re-index this after every change (and those new results appear within a second or two). Because of the small amount of data, this can take a matter of seconds. You will still need to re-index the main dataset regularly though (although how regularly depends on the volatility of your data - every day? every hour?). The fast indexing speeds keep this all pretty painless though.

我不知道这是否适用于您的情况，但Evan Weaver比较了一些常见的Rails搜索选项(Sphinx, Ferret (Lucene的Ruby移植)和Solr)，运行了一些基准测试。我想可能有用。

我还没有深入研究MySQL的全文搜索，但我知道它在速度和功能方面都无法与Sphinx、Lucene或Solr竞争。

SearchTools-Avi说:“MySQL文本搜索，它甚至不能索引三个字母或更少的单词。”

从MySQL 5.0开始，MySQL全文的最小字长是可调的。谷歌'mysql全文最小长度'简单的指令。

也就是说，MySQL全文文本有局限性:首先，一旦你达到一百万左右的记录，它就会变得很慢，……

这是我对这个老问题的看法。我强烈推荐你看看ElasticSearch。

Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式的、支持多租户的全文搜索引擎，具有RESTful web界面和无模式的JSON文档。Elasticsearch是用Java开发的，在Apache许可证的条款下作为开源发布。

相对于其他FTS(全文搜索)引擎的优势是:

rest式接口 更好的可伸缩性 大型社区 由Lucene构建 开发人员 丰富的文档 有很多开放源码库可用(包括Django)

我们在我们的项目中使用这个搜索引擎，并且非常满意。

我会把mnoGoSearch添加到列表中。非常高性能和灵活的解决方案，它作为谷歌:索引器从多个站点获取数据，您可以使用基本标准，或发明自己的钩子，以获得最大的搜索质量。它还可以直接从数据库中获取数据。

这个解决方案今天还不太为人所知，但它满足了最大的需求。你可以编译并安装它，或者在独立的服务器上，甚至在你的主服务器上，它不需要像Solr那样多的资源，因为它是用C编写的，即使在小型服务器上也能完美运行。

一开始你需要自己编译，所以需要一些知识。我为Debian做了一个小脚本，可能会有帮助。欢迎任何调整。

当你使用Django框架时，你可以在中间使用PHP客户端，或者在Python中找到解决方案，我看到了一些文章。

当然，mnoGoSearch是开源的，GNU GPL。

我们刚刚从Elasticsearch切换到Postgres Full Text。因为我们已经使用了Postgres，所以我们现在省去了保持索引更新的麻烦。 但这只影响全文搜索。然而，在某些用例中，Elasicsearch明显更好。也许是面或类似的东西。