在这样的 Windows 文件夹结构中，我们有数十万张 jpg 图像，但很难以快速的方式与它们进行交互和处理（列出需要时间，复制需要时间等）。结构如下：
images/
1/
10001/
10001-a.jpg
10001-b.jpg
...
10001-j.jpg (10 images in each XXXXX folder)
10002/
10003/
...
19999/
2/
20001/
20002/
20003/
...
29999/
3/
4/
5/
6/
7/
8/
9/
现在，浏览这些图像有点慢，因为每个 X 文件夹中大约有 10,000 个文件夹，列出这些文件夹需要时间。
有没有更好的方法来组织包含较少子文件夹/项目的图像？将结构更改为此会有什么效果吗？
images/
1/
0/
0/
0/
0/
1/
2/
3/
4/
5/
6/
7/
8/
9/
10000/ (image folder, same as path)
10000-a.jpg
10000-b.jpg
...
10000-j.jpg (10 images in each image folder)
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
2/
3/
4/
5/
6/
7/
8/
9/
因此，定位图像 48617-c.jpg 将等于路径 4/8/6/1/7/48617/48617-c.jpg。
拥有一个完整路径号为 48617 的单独文件夹的原因是为了简化完整的 10 张图像批次的复制（通过复制整个文件夹）。
现在... 没有一个文件夹会拥有超过 11 个直接子文件夹，但会有很多额外的个位数文件夹用于分隔。这种设置是否会加快浏览速度和多个用户添加/复制/删除/等图像的交互速度？
答案1
在文件夹布局方面，Windows 有点特殊，因为其中包含大量文件。尤其是图像，因为 Windows 资源管理器对它们有特殊对待。话虽如此，但仍有一些指导原则可以遵循，以防止事情变得也不可收拾：
- 如果您出于任何原因想要从 Windows 资源管理器浏览目录结构，请将目录（文件和子目录）中的条目数保持在 10,000 个以下。
- 如果您仅通过 cli 实用程序或代码与其进行交互，则 10K 限制会更加灵活。
- 不要创建太多子目录，您创建的每个目录都是复制时必须进行的另一个离散操作。
- 如果每个文件创建 N 个目录，则文件系统对象该文件创建的大小将是 1+N，这将线性增加您的复制时间。
- 在达到每个目录 10K 的限制之前，一个短的指数树（即三层目录，每层有 256 个子目录）可以惊人地扩展。
- 如果您使用代码访问它，请直接打开，而不是在打开之前解析目录列表。在许多情况下，失败的 fopen() 后跟目录扫描比目录扫描后跟有保证的 fopen() 更快。
注意事项：
- 文件数是不可变的，但目录数由您决定。这两个计数的总和会影响复制操作的速度。
- 如果可能的话，尽量不要使用 Windows 资源管理器进行浏览，除非迫不得已。它不能很好地处理大目录，而且你对此无能为力。
答案2
我的回答中有很多关于数学的好信息目录复杂性对 i 节点有何影响？
话虽如此，不同的文件系统以不同的方式处理目录中的大量文件。有些可以接受 10,000 个条目，而有些则无法接受。根据一个快速发明的经验法则，如果您有设计控制权，1,000 可能是一个不错的目标上限。目录中的条目通常存储为某种列表，由读取应用程序对它们的顺序进行排序。例如，ls在 Unix 世界中，按目录顺序将内容读入内存，然后按字母顺序打印出来。
看看另一个问题的数学计算。还要考虑 sysadmin1338 所说的 Explorer 行为的不同。Explorer 将创建它识别为图像的任何内容的缩略图，然后读取缩略图以显示它们。查看一个塞满文件的目录需要大量的磁盘 IO。
答案3
取决于您是否有资源来开发这样的系统，这听起来像是使用 SQL Server 数据库的一个不错的选择文件流文件的存储。这样，您可以将目录的组织留给 SQL Server，而您只需要担心如何管理数据本身。您可能可以使用 SQL Express，因为在计算数据库大小时不考虑 FILESTREAM 数据。