目录中有多少个文件会降低服务器性能？我有一个网站，其中包含数十万张图片（单独目录中有超过一百万张）。我想知道这是否会影响性能。
服务器详细信息：centos、apache、php 5
答案1
回答这个问题并不容易，但请看一下以下内容：
- /usr/share/lib/terminfo/...
- CPAN 作者/id/...
在这两种情况下，由于条目数量都远少于一百万，因此设计人员将目录分为多个级别以加快访问速度。
如果您有上百万个条目，而文件系统没有在目录处理代码中内置任何搜索结构，那么访问文件将需要操作系统读取目录中每个文件大约一半的名称 + inode 编号条目。即使所有内容都在缓冲池中，这也将成为一项巨大的工作量。
如果引入分层命名系统 - 两个示例均以名称的第一个字符为基础：
terminfo/lib/a/ansi
id/J/JO/JOHNL
CPAN 有两个级别；对于您的 100 万个文件，我可能也会使用两个级别。
拥有额外的目录级别会产生一些开销。
这些方案假设您知道所寻找的名称 - 但搜索所有名称则是另一回事。
答案2
现代文件系统（ext3-4、XFS、ReiserFS 以及许多其他文件系统）可以轻松处理巨大的子目录。这意味着，无论有多少个文件，任何单个操作都需要相当的时间。到目前为止，一切顺利。
但是，有很多操作算作“多次操作”，这些操作在某个时间点之后会退化。最明显的例子是一个简单的ls，它不仅stat()对每个文件执行，而且还对它们进行排序。在大多数情况下，它会导致 O(n (log n)^2) 行为。
另一个痛点是通配符匹配。通常它将是 O(n) 行为，其中 n 是文件总数，而不仅仅是匹配的文件。例如，如果您为每个项目存储一个 JPEG 和一个 GIF，并且想要使用 来获取它们，那么即使该部分完全标识了您想要的项目，item-xx.*也会花费很长时间。（是的，在 SQL 上，a会利用索引；但我还没有看到任何 FS 这样做）item-xxLIKE 'item-xx.%'
简而言之：如果您提供完整且精确的路径，则包含数百万个项目的目录将表现良好。如果有可能要求它完成名称，最好采用层次结构。
答案3
我无法给你任何确切的数字，但确实如此 - 它会降低性能 - 特别是对于涉及列出目录的操作[在你的用例中可能很少发生这些情况，但单个目录中超过几千个条目的想法对我来说是可怕的]。
通常的做法是将事物分解成几个层次的结构：
00/00/
00/01/
00/02/
..
ff/ff/
这样，在每个级别上您都有 256 个目录 [非常少] 并且总共获得 65k 个子文件夹 - 并且在您的情况下每个文件夹中的文件数量减少了 65,000 倍。
看这里类似的问题和答案。