我的Mac应用程序保存了一组对象（带有核心数据），每个对象都有一个封面图像，我在创建时为其分配一个UUID。我最初将封面图像作为字段存储在核心数据存储中，但最近开始将它们存储在文件系统的磁盘上。
最初，我将封面存储在一个平面目录中，使用UUID命名文件，如下所示。这给了我O（1）的吸引力，因为我知道该往哪里看。
...
/.../Covers/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg
/.../Covers/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg
...
不过，我已经研究了其他应用程序处理此任务的方式，并注意到了一个多级方案，如下所示（例如）。这仍然可以在O（1）时间内实现。
...
/.../Covers/A/B/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg
/.../Covers/C/D/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg
...
这样做的原因是什么？OS X是否限制目录中的文件数量？从磁盘中检索它们在某种程度上更快吗？这会使用于计算文件名的代码变得更加复杂，所以我想知道是否有充分的理由这样做。
在某些文件系统（以及我认为的HFS+）上，同一目录中的文件过多会导致性能问题。
我曾经在一家ISP工作，他们会使用多目录方案来分解主目录（他们有90k多个）。您可以使用UUID的前两个字符，然后使用后两个字符对目录进行分区，例如：
/.../Covers/3B/72/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg
/.../Covers/6B/EC/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg
这样你就不需要计算任何额外的字符或代码，只需要使用你已经有的字符或代码来分解它。由于您的UUID每次都会不同，因此这就足够了。
主要原因是，正如您所提到的，在后一种方式中，磁盘检索更快，因为您的目录较小（因此FS将在较小的表中查找文件）。
正如其他人所提到的，在某些文件系统上，操作系统打开文件需要更长的时间，因为一个包含多个文件的目录比几个短目录读取的时间更长。
但是，您应该对特定的文件系统和特定的使用场景进行测量。我在WindowsXP上为NTFS做了这项工作，并惊讶地发现平面目录在各种测试中都比分层结构表现得更好。