我有这个文件夹，叫做'X'。
目前，它有4万个文件夹和70万个文件。
我很担心，里面是图像。 是否有文件夹“X”可以存储的限制？
该文件夹很重要，它存储我目前的用户图像。 请指教？
或者我应该存储在数据库（BLOB）？ 我正在使用MySQL。
请指教。
编辑：
我正在使用Windows Server 2003. IIS 6
和其他一些海报所做的一样，发布理论上的NTFS限制也是非常好的，但是实际上如果你把100k文件放在一个文件夹中，访问这些文件的性能就会大大降低。 这不仅仅是NTFS，而是所有stream行的Linux文件系统。
最简单的方法是把它们分成不超过10k-20k的子文件夹。 如果你的命名是相对均匀分布的，你可以通过文件名的前几个字符来完成，以保持简单。 您想要一次性创build这些文件夹，而不是即时创build，以便根文件夹不被分段。
如果文件很小，并且没有alignment到块的大小，那么在块中也存在浪费空间的问题。 如果是这种情况，那么你可能想看看结合文件来匹配它。
据我所知，一个文件夹中的文件数量没有最大限制，但NTFS的卷上有4,294,967,295个文件的限制。
如果在同一文件夹中有太多文件，Ext文件系统至less会出现性能问题。 我不太确定，但是我会认为NTFS会出现同样的问题。 它接近一个好主意，通过拥有更深的文件夹树，将每个文件夹的文件数量限制在合理的范围内。
“合理的东西”必须在你的环境中进行testing和测量。 我会去10K以下，但这只是一个提示…
如果你使用的是Windows 2003，那么推测你的磁盘是NTFS格式的？
（请 向下滚动到“NTFS大小限制”）查看NTFS的其他相关限制。
但是，如果你在任何地方接近极限，那么你几乎肯定是在做一些错误的事情。
这些数字很大，但不接近NTFS文件系统的限制。 所以，虽然你不会遇到错误，但是当检索目录列表时，你可能会遇到性能问题。
通常，由于内存消耗，目录中的大约6k-10k文件将开始减慢速度。 在大约300k以上的文件中，由于“短文件名生成”难以find唯一的名字，所以文件的创build也将减慢。
将文件存储在一个MySQL blob中是可能的，但是在我看来这很慢并且显着增加了你的数据库。 我会build议创build一个更深的目录结构，并将其当前的结构迁移到它。
您没有指定文件系统或操作系统。 在Linux ext2 （据推测ext3和ext4，因为他们是基于它）有一个1.3×10 ^ 20目录条目的理论极限 。