Unix grep在长搜索词或短搜索词中都能更快地工作吗？

寻找长或短搜索词是否更快？还是根本影响速度？换句话说，您是否应该使搜索字词尽可能准确？

有超过100 000个文件，每个文件包含20到5000多行数据。通常，grep仅用于查找搜索词的一个实例。

假设搜索词为SEARCHTERM，它将像这样连续显示：

NAD+DP+1234567890:92++UNIQUE+NAME+SEARCHTERM++12345+FI'

查找“ SEARCH”或“ SEARCHTERM”是否更快？假设在这种情况下，我们不在乎是否也在其他不相关的行中找到匹配项。

这是我目前的做法：

grep NAD+DP 123* | grep SEARCHTERM

但是我仍然觉得它很慢。即使我知道粗略的文件名，通常也需要3-5分钟才能找到数据，这将范围限制为大约10000个文件。

那么，更长或更短的搜索字词会有所帮助吗？据我所知，grep寻找一定长度的单词“块”吗？

一些参考资料：

GNU grep使用著名的Boyer-Moore算法，该算法首先查找目标字符串的最后一个字母，并使用查找表告诉它，只要找到不匹配的字符，它可以在输入中跳过多远。

摘自为什么GNU grep运行很快。

该算法会预处理要搜索的字符串（模式），但不会预处理正在搜索的字符串（文本）。[...]通常，算法会随着图案长度的增加而更快地运行。

来自Boyer-Moore字符串搜索算法。

结论：使用更长的字符串。

现在，有趣的是一些基准：

# Initialisation
cd $(mktemp -d) && dd if=/dev/urandom of=random bs=1M count=1000
# Version
grep --v` # grep (GNU grep) 2.9
# Benchmark
(for s in 'short' 'this is not so short and we could even consider this as pretty long'; do for t in {1..10}; do time grep "$s" random; done; done ) 2> result

结果：短字符串的平均值为0.952s，长字符串的平均值为0.244s。

注意：长度不是唯一要考虑的标准。

您可以尝试使用SEARCH或SEARCHTERM。另外，请尝试更改两个grep命令的顺序。无论如何，唯一有用的选择是最有可能使用多个CPU内核进行一次搜索。参见parallel命令。

我认为指定更具体的搜索词不会使它明显更快。

要搜索的文件太多，您需要以某种方式索引数据以加快搜索速度。

我可以建议几种方法：

• 创建数据库（PostgreSQL或MySQL），将数据导入数据库-一行中一个文件，添加FTS（全文搜索）索引。创建一些实用程序来查询数据库。

• 以更细粒度的方式将数据导入数据库，可能一行一行（或可能不止一张表），创建索引，以便可以使用索引来搜索数据。创建一些实用程序来查询数据库。

• 将文件添加到git存储库中git gc，使用git grep进行压缩，用于搜索。以我的经验，git grep可以比标准快grep10到100倍。

从逻辑上讲，更短的期限将需要更少的CPU时间，就像grep这样做一样

if (filechar[i] == pattern[i]) ...

更少的时间。实际上，我猜想a grep将是I / O绑定的，而不是CPU绑定的，所以这无关紧要。