我记得我运行了一个程序，它在输出时创建了大量的文件。每个目录按30000个文件进行排序。当我不得不重用产生的输出时，我不记得有任何读取问题。它是在一台32位的Ubuntu Linux笔记本电脑上，甚至Nautilus也显示了目录内容，尽管要等几秒钟。

ext3文件系统:类似的代码在64位系统上处理每个目录64000个文件。

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

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

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

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

我有一个目录，里面有88914个文件。就像你自己，这是用于存储缩略图和在Linux服务器上。

通过FTP或php函数列出的文件是缓慢的，但是在显示文件时也有性能上的影响。例如，www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg的等待时间为200-400毫秒。在另一个网站上，我有一个目录下大约100个文件，在大约40毫秒的等待后，图像就显示出来了。

我给出了这个答案，就像大多数人刚刚写了如何执行目录搜索函数一样，你不会在拇指文件夹上使用它——只是静态地显示文件，但会对如何实际使用文件的性能感兴趣。

我现在正在研究一个类似的问题。我们有一个层次结构的目录结构，并使用映像id作为文件名。例如，其中放置了id=1234567的图像

..../45/67/1234567_<...>.jpg

使用最后4位数字来确定文件的位置。

对于几千张图像，您可以使用一级层次结构。出于效率/备份/其他考虑，系统管理员建议在任何给定目录(ext3)中不超过几千个文件。

≈13.5万份

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

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

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

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

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