如果实现目录分区方案所涉及的时间是最少的，我赞成它。当您第一次调试涉及通过控制台操作10,000个文件目录的问题时，您将能够理解。

例如，F-Spot将照片文件存储为YYYY\MM\DD\filename。ext，这意味着在手动操作我的~20000张照片集合时，我必须处理的最大目录大约有800个文件。这也使文件更容易从第三方应用程序中浏览。永远不要以为只有你的软件会访问你的软件文件。

请记住，在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

这完全取决于文件系统。许多现代文件系统使用良好的数据结构来存储目录的内容，但旧的文件系统通常只是将条目添加到列表中，因此检索文件是一个O(n)操作。

即使文件系统做得正确，列出目录内容的程序仍然绝对有可能搞砸并执行O(n^2)排序，因此为了安全起见，我总是将每个目录的文件数量限制在不超过500个。

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

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

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

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

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

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