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