最近，有人在一个非技术论坛上告诉我，将文件嵌套在太多子文件夹中会降低计算机的速度。这是真的吗？这有点道理，因为计算机会有更大的文件系统索引或任何名称来进行排序，但我在网上找不到有关这方面的任何信息。我实际上并没有注意到在我的计算机上创建大量文件夹有什么不同，而且我以前从未听说过（我读过很多关于技术的文章），所以我有点怀疑。有人能好心地告诉我一些相关信息吗？
答案1
据我所知，最好拥有多个包含少量文件的文件夹，而不是拥有一个或几个包含大量文件的文件夹。
每个文件夹都存储每个文件/文件夹（链接）的索引信息。因此，如果您的文件夹中有 1,000,000 个文件，那么它将存储 1,000,000 个条目，加载速度会很慢。
但是，如果您有 10 个文件夹，每个文件夹有 100,000 个文件，那么它将只存储 10 个条目，每个子文件夹中有 100,000 个条目。
这只是一个简单的例子，但我希望您明白我的意思。
我想如果你有数百万个包含文件/文件夹的文件夹，那么这将是一个问题。
另请阅读：文件夹太大会有问题吗？
答案2
一般来说不会，但是文件系统行为中有很多变量，因此在某些情况下可能会产生影响。
对于日常运行，它只对您（或代表您的应用程序）正在访问的目录有影响。如果一个目录中有大量文件和子目录（几千个或更多），您可能会遇到基于 FAT 的文件系统的性能问题，因为那里的目录列表以相对非结构化的方式存储，但对于 NTFS 来说情况并非如此，因为列表存储在索引结构中，搜索和修改效率更高（如果您也使用 Linux，ext2 和 ext3/ext4/较新的文件系统之间也有类似的差异）。任何给定目录中的对象数量都有绝对限制，但您很少会达到这些限制（对于 FAT32，它们的数量约为 32,000，对于 NTFS，它们的数量约为 4,000,000,000）。
如果您的目录结构很深（例如c:\this\is\a\directory\structure\with\many\many\many\many\levels\my\god\look\how\deep\it\goes）和/或其中包含一些长名称，那么您将达到旧的 260 个字符路径限制。据我所知，Windows API 和内置库和工具（包括 Explorer）可以处理最近发布的更长的路径，但您会发现许多第三方实用程序仍然假设并强制执行该限制（或者如果遇到超过该限制的路径，则会失败）。此外，一些第三方工具在查看包含大量文件/子目录的单个目录时会表现得效率低下。
如果文件系统中有很多对象（文件、目录或两者），那么任何文件系统范围的操作（例如通过一致性检查）chckdsk当然会花费更长的时间。