Question

假设我正在设计一个工具，可以在PostgreSQL / MySQL数据库或文件系统中保存代码片段。我想搜索这些片段。使用像Sphinx这样的搜索引擎似乎并不实用，因为我们在搜索代码时需要精确的代码文本匹配。

grep和ack并且一直很好用，但是将数据存储在数据库中会使得大量的东西在某些方面更易于管理。我想知道在一个目录树上递归运行grep的相对性能与运行像SQL的LIKE或MySQL的REGEXP函数的查询相比，在TEXT blob的同等数量的记录上运行。

Answer 1

如果你有1M个文件要通过，你会（最好我知道）用正则表达式来浏览每个文件。

对于所有意图和目的，如果使用LIKE运算符或正则表达式对它们进行大量查询，则最终会对表行执行相同的操作。

我自己使用grep的经验是，我很少寻找不包含至少一个完整单词的内容，因此您可以利用数据库来减少搜索的集合。

MySQL具有原生全文搜索功能，但我建议反对，因为它们意味着您没有使用InnoDB。

你可以在这里阅读有关Postgres的内容：

在tsvector列上创建索引之后，您可以分两步执行“grep”，一个用于立即查找可能含糊不清的行，然后按照您的真实条件查找另一个：

select * from docs where tsvcol @@ :tsquery and (regexp at will);

这将比grep可以做的任何事情都快得多。

Answer 2

我无法比较它们，但两者都需要很长时间。我的猜测是grep会更快。

但MySQL支持full text indexing and searching，这将比grep更快 - 我再次猜测。

另外，我不明白，Sphinx或Lucene有什么问题。无论如何，这是一个benchmark for MySQL, Sphinx and Lucene

Answer 3

互联网似乎猜测grep使用Boyer-Moore，这将使查询时间与查询大小相加（而非乘法）。但这并不相关。

我认为这对于一次性搜索几乎是最佳的。但是在你的情况下，你可以做得更好，因为你有重复搜索，你可以利用它的结构（例如通过索引查询中的某些常见子串），如bpgergo暗示的那样。

此外，我不确定您正在考虑使用的正则表达式引擎是否针对非特殊查询进行了优化，您可以尝试并查看。

您可能希望将所有正在搜索的文件保留在内存中，以避免基于硬盘的减速。除非您正在搜索大量文本，否则这应该有效。

Answer 4

如果你想要代码的全文索引，我会推荐Russ Cox的代码搜索工具 https://code.google.com/p/codesearch/