没有一个数字是“太多”的，只要它不超过操作系统的限制。然而，不管哪种操作系统，一个目录中的文件越多，访问任何单个文件所需的时间就越长，而且在大多数操作系统上，性能是非线性的，因此从10,000个文件中找到一个文件所需的时间是在1,000个文件中找到一个文件所需的时间的10倍以上。

与目录中有大量文件相关的次要问题包括通配符展开失败。为了降低风险，您可以考虑根据上传日期或其他有用的元数据对目录进行排序。

我遇到的最大问题是在32位系统上。一旦你通过了一个特定的数字，像'ls'这样的工具就会停止工作。

一旦您通过了这个障碍，试图对该目录做任何事情都将成为一个巨大的问题。

问题归结为你将如何处理这些文件。

在Windows下，对于我来说，在资源管理器中打开任何超过2k个文件的目录都比较缓慢。如果它们都是图像文件，在缩略图视图中，超过1k的文件往往打开得非常慢。

系统规定的上限曾一度是32767个。现在它更高了，但即使如此，在大多数情况下，一次处理的文件也太多了。

我尊重这并不能完全回答你的问题，多少是太多了，但解决长期问题的一个想法是，除了存储原始文件元数据外，还存储它存储在磁盘上的哪个文件夹-规范化元数据。一旦一个文件夹的增长超出了性能、美观或其他原因的限制，你只需创建第二个文件夹并开始在那里放置文件……

不管怎样，我只是在ext4文件系统上创建了一个目录，其中有1,000,000个文件，然后通过web服务器随机访问这些文件。我没有注意到访问这些文件比(比如说)只有10个文件有任何溢价。

这与我几年前在ntfs上做这件事的经验完全不同。

≈13.5万份

NTFS | Windows 2012 server | 64bit | 4tb HDD | VBS

问题:当[单个]特定文件夹聚集了大约135,000个文件时，会出现灾难性的硬件问题。

“灾难性”= CPU过热，计算机关闭，更换硬件需要 "Specific Folder" =有一个VBS文件，用于将文件移动到子文件夹中 访问=该文件夹被多个客户端计算机自动访问/执行

基本上，我有一个位于文件服务器上的定制脚本。当自动化过程出现问题时(例如，文件溢出+大坝)，那么特定的文件夹会被淹没[未移动的文件]。当客户端计算机继续执行脚本时，灾难就形成了。文件服务器最终读取了135,000多个文件;每天这样做几百次。这种工作过载最终导致我的CPU过热(92°C等);结果导致我的机器崩溃。

解决方案:确保您的文件组织脚本永远不必处理包含135,000多个文件的文件夹。