一个目录中有多less个文件会降低服务器的性能？ 我有一个网站，其中包含数十万的图像（>百万分隔的目录）。 我想知道这是否会影响performance。
服务器细节：centos，apache，php 5
回答这个问题并不是一个简单的方法，而是看看像这样的事情：
在这两种情况下，devise人员将目录分成多个级别，以加快访问速度。
如果有一百万个条目并且文件系统没有内置到目录处理代码中的任何search结构，那么访问一个文件将要求o / s读取目录中名称+ inode号码条目的一半文件。 即使全部在缓冲池中，这也是一个很大的工作量。
如果您引入分层命名系统 – 这两个示例都基于名称的第一个字符：
terminfo/lib/a/ansi id/J/JO/JOHNL CPAN有两个层次; 对于你的100万个文件，我可能也会使用两个层次。
有额外的目录级别有一些开销。
这些计划假定你知道你正在寻找的一个名字 – 通过所有的名字search是一个不同的命题。
现代的文件系统（ext3-4，XFS，ReiserFS，还有很多其他的）可以很容易地处理巨大的子目录。 这意味着任何一个单独的操作都需要相当的时间，而不是有多less文件在那里。 到现在为止还挺好。
但是，有很多操作被认为是“很多操作”，而这些操作在某个点之后会降级。 最明显的例子是一个简单的ls ，它不仅对每个文件执行一个stat() ，还对它们进行sorting。 在大多数情况下，它会导致O（n（log n）^ 2）行为。
其他痛点是通配符匹配。 通常这是一个O（n）行为，其中n是文件的总数，而不仅仅是匹配的文件。 例如，如果您为每个项目存储一个JPEG和一个GIF，并且想要使用item-xx.*获取它们，则即使item-xx部分完全标识了您想要的项目，也需要很长时间。 （是的，在SQL上LIKE 'item-xx.%'会利用索引;但是我没有看到任何FS做这个）
简而言之，如果您提供完整且精确的path，那么数百万个项目的目录将performance良好。 如果有可能要求它填写名称，最好采用分层结构。
我不能给你任何硬数字，但是是的 – 它会降低性能 – 特别是涉及列出目录的操作[可能在你的用例中发生的那些事情很less，但是仍然有一个想法，在单个目录中有超过几千个条目对我来说是可怕的]。
通常的做法是把事情分解成几个层次的结构：
00/00/ 00/01/ 00/02/ .. ff/ff/
通过这种方式，每个级别上有256个dirs（非常less），总共可以获得65k个子文件夹，而在您的情况下，每个文件夹中的文件减less65 000个。
看到这里类似的问题和答案。