我想写一个缓存文件夹来存储计算数据，因此我不必每次都重新计算它，输入相同的输入数据。 所以我计算输入数据的哈希值（例如输入文件上的哈希值），将其转换为允许字符串并希望将其用作公共缓存目录中的文件名，这样我就可以快速找到计算出的数据哈希。缓存文件的数量不会非常大（<10000），所以我认为使用单个文件夹应该不是问题。
通常问题是，高级用户可能希望以更智能的方式删除不再需要的缓存数据，以删除整个缓存。所以我认为在文件名中包含额外的人类可读信息（例如输入文件的原始文件名）是一个不错的选择。然后，缓存文件名将具有以下结构：
columnShow: function (e) {
e.sender.dataSource.read();
}
其中<hash>_<info>.<extension>
是_中禁止的任何分隔字符。
当然，我会关心的是，只有一个文件具有相同的哈希值，就像第一个缓存文件获胜并阻止创建一个新文件。
现在我的问题是，这是否会影响使用请求的哈希搜索文件的性能？没有附加信息，我有一个固定的文件名，我只是搜索。但是添加了信息后，我需要搜索以请求的哈希值开头的文件，例如使用<hash>中的通配符。
据我所知，NTFS使用B + Tree来组织目录中的文件名。因此，无论是搜索固定文件名还是搜索带有通配符的文件名，它都会遍历树。所以我想重要的部分必须是文件名的开头，最后是不重要的部分。但使用通配符搜索是否有任何性能损失？如果，是否有可能解决这个问题？
如果重要的话，我会使用<hash>_*.<extension>之类的内容在C＃中编写，但我会打开其他建议。
答案 0 :(得分：0)
NTFS可以足够聪明地为非元字符文本执行前缀查找（例如＆＃34; hash _ * .ext＆＃34;）。所以你可以＆gt;找到＆lt;文件但是要打开会意味着再次遍历事物。
此外，添加额外信息会降低每个BTree页面中条目的密度，这意味着在查找文件时可能会有更多页面需要搜索。
我保持名称尽可能短，以满足您的开放性能需求，并将人类可读的信息粘贴到备用数据流中。在做＆＃34; dir＆＃34;时，你不会看到这些信息，但它可能是任意大的。