我的 PHP 项目将使用数千张图片，每张图片只需要一个数字作为其存储名称。
我最初的想法是将所有图片放在一个目录中，并将文件命名为“0.jpg”、“1.jpg”、“2.jpg”，一直到“4294967295.jpg”。
创建目录树结构并将文件命名为“429 / 496 / 7295.jpg”之类的文件在性能方面会更好吗？
如果答案是肯定的，那么后续问题将是：每个深度级别的子目录或文件的最佳数量是多少？选择的文件系统对此有什么影响？
每个文件都有一个对应的 MySQL 条目，带有一个 UNSIGNED LONGINT id-number。
谢谢你。
传统观点是“使用数据库”，但使用文件系统对于像图像这样的较大对象是一个合理的计划。
一些文件系统对目录条目的数量有限制。一些文件系统没有用于文件名查找的任何类型的数据结构，而只是对目录进行线性扫描。
您正在讨论的优化仅限于特定的环境配置文件。您现在是否知道您的应用程序将在未来的哪些硬件上运行？不强调文件系统并创建一个漂亮的分层目录结构可能是一个好主意吗？如果你这样做，它将在任何文件系统或存储服务器上运行良好。
在一个目录中有数千个文件会大大减慢速度。我想说一个安全的数字是每个目录最多 1024 个文件，512 个甚至更好。
这取决于正在使用的文件系统。ext{2,3,4} 有一个 dir_index 选项，可以在创建它们时设置它，这使得在单个目录中存储数千甚至数百万个文件相当快。
btrfs 还没有准备好生产，但它在一个非常基本的级别上隐含地支持这个想法。
但是，如果您使用的是没有 dir_index 的 ext 系列或大多数其他 Unix 文件系统，您将需要采用具有多个目录级别的更复杂的方案。如果可以的话，我建议你避免这种情况。它只是为文件系统应该为您合理处理的事情增加了很多额外的复杂性。
如果您确实使用更复杂的方案，我建议将数字编码为十六进制，并在每个级别有 256 个文件/目录。不是为处理每个目录中的大量文件而设计的文件系统通常会进行线性扫描。目标是自己逼近一个 B-Tree 类型的结构。每个级别的 2 个十六进制数字为您提供每个级别大约一半 4kiB（常见大小）的磁盘块，并具有通用的目录编码方式。这与没有非常复杂的方案（例如以 23 或 24 为基数编码您的数字）的情况一样好。
答案当然是：视情况而定。
特别是，它取决于您使用的文件系统。例如，ext2和ext3文件系统对每个目录的文件数有限制。那些文件系统无法将您所有的图片放在一个目录中！
您可能会查看文件系统以外的其他内容。在我工作的公司中，因为我们需要存储大量资料，我们从基于文件的存储转移到在Apache Jackrabbit上运行的基于数据库的存储。