我也有同样的问题。试图在ext4的Ubuntu服务器中存储数百万个文件。结束运行我自己的基准测试。发现平面目录执行得更好，同时使用起来更简单:

写了一篇文章。

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

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

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

请记住，在Linux上，如果目录中有太多文件，shell可能无法展开通配符。我在Linux上托管的相册有这个问题。它将所有调整大小的图像存储在一个目录中。虽然文件系统可以处理许多文件，但shell不能。例子:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

or

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

这实际上取决于所使用的文件系统，以及一些标志。

例如，ext3可以有数千个文件;但在几千次之后，它就变得非常缓慢了。主要是在列出目录时，但也在打开单个文件时。几年前，它获得了“htree”选项，这极大地缩短了给定文件名获取inode所需的时间。

就我个人而言，我使用子目录将大多数级别保持在1000个左右的项目以下。在您的例子中，我将创建256个目录，使用ID的最后两个十六进制数字。使用最后一个数字，而不是第一个数字，这样可以实现负载平衡。

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

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

Ext3实际上有目录大小限制，它们取决于文件系统的块大小。没有每个目录的文件“最大数量”，而是每个目录的“用于存储文件条目的最大块数量”。具体来说，目录本身的大小不能超过高度为3的b-树，并且树的扇出取决于块大小。有关详细信息，请参见此链接。

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

我最近在一个格式化为2K块的文件系统上就遇到过这种情况，它莫名其妙地得到目录已满的内核消息警告:ext3_dx_add_entry:目录索引已满!当我从另一个ext3文件系统复制时。在我的例子中，一个只有480,000个文件的目录无法复制到目标。