目录中有多少文件太多（在 Windows 和 Linux 上）？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2994544/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How many files in a directory is too many (on Windows and Linux)?
提问by Rhubarb
Possible Duplicate:
How many files in a directory is too many?
可能的重复：
一个目录中有多少文件太多了？
I was told that putting too many files in a directory can cause performance problems in Linux, and Windows. Is this true? And if so, what's the best way to avoid this?
有人告诉我，在一个目录中放置太多文件会导致 Linux 和 Windows 中的性能问题。这是真的？如果是这样，避免这种情况的最佳方法是什么？
采纳答案by mdma
According to this Microsoft article, the lookup time of a directory increases proportional to the square of the number of entries. (Although that was a bug against NT 3.5.)
根据这篇 Microsoft 文章，目录的查找时间与条目数的平方成正比。（尽管这是针对 NT 3.5 的错误。）
A similar question was asked on the Old Joel on Software Forum. One answer was that performance seems to drop between 1000 and 3000 files, and one poster hit a hard limit at 18000 files. Still another post claims that 300,000 files are possible but search times decrease rapidly as all the 8.3 filenames are used up.
在Old Joel on Software Forum 上提出了类似的问题。一个答案是性能似乎在 1000 到 3000 个文件之间下降，并且一张海报达到了 18000 个文件的硬限制。还有一篇文章声称可能有 300,000 个文件，但随着所有 8.3 文件名都用完，搜索时间会迅速减少。
To avoid large directories, create one, two or more levels of subdirectories and hash the files into those. The simplest kind of hash uses the letters of the filename. So a file starting abc0001.txt would be placed as a\b\c\abc0001.txt, assuming you chose 3 levels of nesting. 3 is probably overkill - using two characters per directory reduces the number of nesting levels. e.g. ab\abc0001.txt. You will only need to go to two levels of nesting if you anticipate that any directory will have vastly more than ca. 3000 files.
为避免大目录，请创建一层、两层或多层子目录并将文件散列到这些子目录中。最简单的散列使用文件名的字母。因此，假设您选择了 3 级嵌套，以 abc0001.txt 开头的文件将被放置为 a\b\c\abc0001.txt。3 可能有点矫枉过正——每个目录使用两个字符会减少嵌套级别的数量。例如ab\abc0001.txt。如果您预计任何目录的数量将远远超过 ca，则您只需要进行两级嵌套。3000 个文件。
回答by Romain Hippeau
The Windows file system is currently NTFS. The max amount of files on a volume is 4,294,967,295. File cataloging on the drive takes place in a B+ Tree which gives you a Log(N) lookup.
Windows 文件系统当前是 NTFS。卷上的最大文件数为 4,294,967,295。驱动器上的文件编目发生在 B+ 树中，它为您提供 Log(N) 查找。
On the old FAT32 there was a limit of 64K files in a folder. Indexing was also done by a list per folder, therefore after a couple of thousand performance dropped off drastically. You probably do not need to worry about FAT32, unless your audience has DOS, windows 95,98 or Millenium (Yuck).
在旧的 FAT32 上，文件夹中的文件限制为 64K。索引也是由每个文件夹的列表完成的，因此在几千次之后性能急剧下降。您可能不需要担心 FAT32，除非您的听众有 DOS、Windows 95,98 或 Millenium (Yuck)。
On Linux it really depends on the File System you are using (It could be NTFS if you decide to do so) extf3 has a limitation of 32k files per directory. The lookup is also B+ Tree and will give you LOG(N) lookup
在 Linux 上，它实际上取决于您使用的文件系统（如果您决定这样做，它可能是 NTFS）extf3 限制为每个目录 32k 个文件。查找也是 B+ 树，会给你 LOG(N) 查找
After looking this through further your question should really be regarding limitations of file systems.
在进一步查看后，您的问题应该是关于文件系统的限制。
