在SO上有很多讨论关于目录中有多少文件是合适的：在较旧的文件系统上保持低于千万以下的新版本低于几十万。 通常建议是为每几千个文件创建子目录。
所以下一个问题是：我应该放入目录的子目录的最大数量是多少？将它们嵌得太深会导致dir树遍历性能。有没有将它们嵌套到浅层？
答案 0 :(得分：2)
从实用角度来看，应用程序可能无法处理大型目录条目。 例如，Windows资源管理器陷入困境，有数千个目录条目（我遇到了Vista崩溃，但XP似乎更好地处理了它。）
由于您提到了嵌套目录，因此请记住，完全限定（带驱动器指示符和路径）文件名(See wikipedia 'filename' entry)的长度有限制。这将随操作系统文件系统(See Wikipedia 'comparison on file systems' entry)而变化。
对于Windows NTFS，它应该是255，但是，我遇到了命令和API函数的问题，其中包含大约120个字符的完全限定文件名。我在映射的网络驱动器上也存在长路径名称的问题（至少使用Vista和I.E.Explorer 7）。
子目录的嵌套级别也有限制。例如，CD-ROM（ISO 9660）限制为8个目录级别（如果您想将目录结构复制到CD-ROM或其他文件系统，请记住这一点。）
因此，当您将文件系统推向极端时会出现很多不一致 （虽然文件系统可能在理论上处理它，但应用程序和库可能不会）。
答案 1 :(得分：1)
确实取决于您使用的操作系统，因为目录操作是使用系统调用完成的。对于基于unix的操作系统，i-node查找算法非常高效，目录中的文件和文件夹数量无关紧要。也许这就是为什么在基于Unix的系统中没有限制的原因。但是，在Windows中，it varies from file-system to file-systems。
答案 2 :(得分：0)
通常，现代文件系统（如NTFS或ext3）在直接访问文件时没有问题（例如，如果您尝试打开/foo/bar/baz.dat）。你可以遇到问题的地方是枚举给定目录中的子目录/文件（即从/ foo给我所有文件/目录）。这可能发生在多种情况下（例如在调试时或在备份期间等）。我发现将子计数保持在最多几百左右，这给了我可接受的响应时间。
当然，这种情况因情况而异，所以请测试： - ）
答案 3 :(得分：0)
我的猜测尽可能少。
在我工作的ISP（2003年）我们有很多用户电子邮件和网络文件。我们使用md5哈希用户名构建它们，深度为3级（即/ home / a / b / c / abcuser）。这导致第三级目录中最多可能有100个用户。
您也可以在浅层结构中使用用户目录制作更深层次的结构。最好的选择是尝试查看，但查找速度越快，目录计数越小。
答案 4 :(得分：0)
我最近遇到过类似的情况。我们使用文件系统来存储序列化的交易细节。这些只是不经常查看，将它们存储在数据库中是不值得的。
我们发现Windows和Linux处理了大约一千个文件，但它访问它们的速度要慢得多 - 我们在逻辑分组中将它们组织在子目录中，这解决了这个问题。
它们也更容易受到影响。浏览数千个文件比更改为正确的子目录和数百个文件要慢。
答案 5 :(得分：0)
我发现UFS2的限制大概是2 ^ 15个子目录。因此，虽然UFS2和oder现代文件系统在目录中使用了几十万个文件，但它只能处理相对较少的子目录。非显而易见的错误消息是“无法创建链接”。
虽然我没有测试过ext2但是我发现了各种邮件列表帖子，其中海报也在ext2文件系统上存在超过2 ^ 15个文件的问题。
答案 6 :(得分：0)
在Windows API中，maximum length设置为260个字符。 unicode函数确实将此限制扩展为32767个字符，主要文件系统使用该字符。
答案 7 :(得分：-1)
说真的，我想不到很多情况下，我的子目录中甚至会有一千个文件。当然不是可执行文件或配置类型。
也许日志类型的文件可以获得这些数字但是，即使你每分钟都在创建一个日志文件（为什么会这样？），那一天仍然只有1400多个。
然后每天只有一个子目录，到达一千个子目录需要几年时间。