NTFS 文件目录搜索性能

Question

我想写一个缓存文件夹来存储计算数据，所以我不必每次都重新计算它，相同的输入数据进来。 所以我计算输入数据的哈希（例如输入文件的哈希），将其转换为允许的字符串，并希望将其用作公共缓存目录中的文件名，因此我可以使用快速找到计算数据哈希。缓存文件的数量不会很大（

通常问题是，高级用户可能希望以更智能的方式删除不再需要的缓存数据，以删除整个缓存。所以我认为在文件名中包含额外的人类可读信息（例如输入文件的原始文件名）是一个不错的选择。缓存文件名将具有以下结构：

<hash>_<info>.<extension>

其中_ 是<hash> 中禁止的任何分隔字符。 当然，我会关心，只有一个文件具有相同的哈希值，就像第一个缓存文件获胜并阻止创建新文件一样。

我现在的问题是，这会影响搜索具有请求哈希的文件的性能吗？如果没有其他信息，我将有一个固定的文件名，我只需搜索即可。但是添加信息后，我需要搜索以请求的哈希开头的文件，例如使用通配符，如<hash>_*.<extension>。

据我了解，NTFS 使用 B+Tree 来组织目录内的文件名。因此，无论我搜索固定文件名还是带有通配符的文件名，它都会在任何情况下遍历树。所以我猜重要的部分必须在文件名的开头，而不重要的部分在结尾。但是使用通配符进行搜索是否会对性能造成影响？如果，有没有可能解决这个问题？

如果重要，我会用 C# 编写它，使用 Directory.EnumerateFiles() 之类的东西，但我愿意接受其他建议。

Answer 1

NTFS 可能足够聪明，可以对非元字符文本（如“hash_*.ext”）进行前缀查找。因此，您可以 >find

此外，添加额外信息会降低每个 BTree 页面中条目的密度，这意味着在查找文件时可能需要搜索更多页面。

我会尽量缩短名称，以满足您的开放性能需求，并将人类可读的信息粘贴到备用数据流中。执行“dir”时您不会看到该信息，但它可以任意大。