我有一个基于 Linux 的应用程序（Drupal - PHP + Apache + MySQL），它可以快速扩展以在同一个文件夹中保存数千张图片。我现在可能接近2,000。在一个文件夹中有这么多图像有什么缺点吗？它能否代表性能方面的影响？
我不打算浏览该文件夹中的文件，服务器只是在请求其 URL 时提供图像，但我想知道我将来是否会遇到问题（应用程序正在缩放，根据图片数量进行缩放，它可以达到 20,000、30,000 张图像……）。也许我应该计划一个将这个巨大的图像文件夹拆分为子文件夹的策略，例如使用子文件夹的用户名，或者图片上传的年份月份。
简而言之，问题是：在 Linux 服务器的同一个文件夹中拥有数千张图像是否很糟糕（不确定我的应用程序使用的是哪种风格，它实际上是在共享托管环境中）？我应该做些什么来避免这种方法并将这些项目分成子文件夹吗？关于每个文件夹的文件数或每个文件夹的最大文件数是否有任何建议？
感谢您分享您对此的看法。
它在很大程度上取决于文件系统（以及挂载选项）。
最近的文件系统（ext4，btrfs ....）能够处理包含大量文件的巨大目录（因此可能可以处理包含半百万个文件的目录）。
但是，在需要fsck多 TB 文件系统的极少数情况下，您不会感到高兴！
但是，shell（和通配函数 - 读取glob(7)和glob(3)等...）可能对包含数千个条目的目录不满意。（考虑到交互式 shell 中的自动完成功能可能需要扫描目录）。如果ls需要一分钟来回答数千行，那么人类用户（例如一些系统管理员）可能会发疯......
我建议每个目录不要超过几千个文件（包括子目录）。考虑组织你的图像，如a0/001.png............等a0/999.png a1/001.png......a1/999.pngb9/
如果你真的有很多文件，你可能想为它们使用不同的文件系统（例如a0/......a9/在一个磁盘上和b0/......b9/在另一个磁盘上）......或者使用LVM，或者可能是OpenStack Swift对象存储或煤渣块存储等。
还要查看Nosql数据库...
顺便说一句，如果您的目标是扩展到 PB 存储，事情将变得不那么容易......
您可能希望至少在某些数据库中存储文件的名称。