在构建Web应用程序时，我们经常会有与数据库条目相关联的文件，例如：我们有一个 user 表，每个类别都有一个 avatar 字段，该字段保存相关图像的路径 .
为了确保文件名中没有冲突，我们可以：
-
上传到
ID.jpg时重命名文件;然后路径/user-avatars/ID.jpg -
或为每个实体创建一个子目录，并保留原始文件名;然后路径
/user-avatars/ID/original_filename.jpg
其中ID是 users 的唯一ID号
从应用程序逻辑的角度来看，两者都是完全有效的 .
但从文件系统性能的角度来看哪一个会更好？我们必须记住， category 条目的数量可能非常高（数百万） .
目录可以容纳多个子目录是否有限制？
3 回答
这将取决于你的文件系统，但我会假设你正在谈论像ext3这样简单的东西，你并没有运行分布式文件系统（其中一些非常擅长） . 通常，文件系统在单个目录中的一定数量的条目上表现不佳，无论这些条目是目录还是文件 . 因此，无论您是为每个映像创建一个目录还是在根目录中创建一个映像，都会遇到扩展问题 . 如果你看看这个答案：
How many files in a directory is too many (on Windows and Linux)?
您将看到ext3在目录中的大约32K条目中遇到限制，远远低于您提议的条目 .
在我的脑海中，我建议对多级目录树进行一些基本的分片，比如/user-avatars/1/2/12345/original_filename.jpg . （或者适合您的ID类型的东西，但我将您的问题解释为关于数字ID . ）当您决定要在存储群集中分发时，这样做也会使您的生活更轻松，因为您可以传播目录周围 .
对于任何文件系统，一个父目录中的数百万个条目（文件或目录）将难以处理 . 虽然现代文件系统使用排序和各种树算法来快速搜索所需文件，但即使使用Windows资源管理器或Midnight Commander或任何其他文件管理器导航到该文件夹也会很复杂，因为文件管理器必须读取目录的内容 . 这同样适用于文件搜索 . 因此，子目录是首选 .
但我需要注意的是，当所有文件都在一个目录中时，访问特定文件会比将它们分成子目录至少在NTFS上更快（用400K文件自己测量几次） .
如果你真的想使用文件，也许你最好的办法是将文件分成几个子目录，这样就不会达到极限 . 例如，如果您的ID为123456，则可以将其放在/12/34/56.jpg中 .
但是，我建议只使用数据库来存储这些数据，因为您已经在使用它 . 您可以将图像数据和ID存储在同一个表中，并且您不必担心处理文件的某些麻烦事务，例如确保权限设置正确等 .