这里有一些建议，来自某个环境中的人，我们有包含数千万文件的文件夹。
1.文件夹将索引信息（指向子文件的链接和子文件夹）存储在索引文件中。当您有很多子文件时，此文件将变得非常大。请注意，它不会区分是文件夹的子文件和是文件的子文件。唯一的区别是子文件的内容是子文件的文件夹索引或子文件的文件数据。注意：我把这个问题简化了一些，但这就把重点讲清楚了。
1.索引文件将变得碎片化。当它变得过于碎片化时，您将无法将文件添加到该文件夹。这是因为允许的碎片数量有限制。这是设计的。我已经在支持事件电话中与Microsoft确认了这一点。因此，尽管文件夹中可以包含的文件数量的理论限制是数十亿，祝你好运，当你开始击中数以千万计的文件，因为你将击中碎片限制第一。
1.这并不全是坏事。你可以使用这个工具：contig.exe对该索引进行碎片整理。它不会减少索引的大小（对于数千万个文件，可能会达到几个Gigs），但可以减少碎片的数量。注意：磁盘碎片整理工具不会对文件夹的索引进行碎片整理。它会对文件数据进行碎片整理。只有contig.exe工具会对索引进行碎片整理。仅供参考：您也可以使用它来整理单个文件的数据。
1.如果你做碎片整理，不要等到你达到最大碎片数限制。我有一个文件夹，我不能碎片整理，因为我已经等到太晚了。我的下一个测试是尝试移动一些文件从该文件夹到另一个文件夹，看看我是否可以碎片整理它。如果这失败了，然后我将不得不做的是1）创建一个新文件夹。2）移动一批文件到新文件夹。3）整理新文件夹。重复#2 & #3直到这完成，然后4）删除旧文件夹并重命名新文件夹以匹配旧文件夹。
更直接地回答您的问题：如果您正在查看10万个条目，请不要担心。请尽情发挥。如果您正在查看数千万个条目，请选择：
a）制定计划，将它们细分为子文件夹（例如，假设您有100M文件。最好将它们存储在1000个文件夹中，这样每个文件夹中只有100，000个文件，而不是将它们存储在一个大文件夹中。这将创建1000个文件夹索引，而不是一个更有可能达到最大碎片数限制的大文件夹索引。
B）制定计划定期运行contig.exe，以保持大文件夹的索引碎片整理。

实际的限制不是片段的数量，而是存储指向片段的指针的数据段的记录数量。
所以你有一个数据段，它存储指向目录数据片段的指针。目录数据存储关于目录应该存储的子目录和子文件的信息。实际上，目录并不“存储”任何东西。它只是一个跟踪和表示功能，向用户呈现层次结构的错觉，因为存储介质本身是线性的。

创建短文件名也会降低性能。Microsoft建议，如果文件夹中的文件超过300k，请关闭短文件名创建[1]。前6个字符的唯一性越低，问题就越大。
[1][How NTFS Works](http://technet.microsoft.com/en-us/library/cc781134.aspx)来自http://technet.microsoft.com，搜索“300，000”

我正在构建一个文件结构来托管多达20亿（2^32）个文件，并执行了以下测试，结果显示在固态驱动器（SSD）上每个NTFS目录大约有250个文件或120个目录时，导航+读取性能急剧下降：

• 在250到1000个文件之间，文件性能下降50%。
• 目录性能在120到1000个目录之间下降60%。
• 数值〉1000保持相对稳定

有趣的是，目录和文件的数量并没有明显的影响。
所以教训是：

• 文件号超过250的成本系数为2
• 高于120的目录的成本系数为2.5
• Windows 7中的文件资源管理器可以处理大型#Files或#Dirs，但可用性仍然很差。
• 引入子目录并不昂贵

这是数据（每个文件和目录有2个测量值）：

(FOPS = File Operations per Second)
(DOPS = Directory Operations per Second)

#Files  lg(#)   FOPS    FOPS2   DOPS    DOPS2
   10   1.00    16692   16692   16421   16312
  100   2.00    16425   15943   15738   16031
  120   2.08    15716   16024   15878   16122
  130   2.11    15883   16124   14328   14347
  160   2.20    15978   16184   11325   11128
  200   2.30    16364   16052   9866    9678
  210   2.32    16143   15977   9348    9547
  220   2.34    16290   15909   9094    9038
  230   2.36    16048   15930   9010    9094
  240   2.38    15096   15725   8654    9143
  250   2.40    15453   15548   8872    8472
  260   2.41    14454   15053   8577    8720
  300   2.48    12565   13245   8368    8361
  400   2.60    11159   11462   7671    7574
  500   2.70    10536   10560   7149    7331
 1000   3.00    9092    9509    6569    6693
 2000   3.30    8797    8810    6375    6292
10000   4.00    8084    8228    6210    6194
20000   4.30    8049    8343    5536    6100
50000   4.70    7468    7607    5364    5365

这是测试代码：

[TestCase(50000, false, Result = 50000)]
[TestCase(50000, true, Result = 50000)]
public static int TestDirPerformance(int numFilesInDir, bool testDirs) {
    var files = new List<string>();
    var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\";
    Directory.CreateDirectory(dir);
    Console.WriteLine("prepare...");
    const string FILE_NAME = "\\file.txt";
    for (int i = 0; i < numFilesInDir; i++) {
        string filename = dir + Guid.NewGuid();
        if (testDirs) {
            var dirName = filename + "D";
            Directory.CreateDirectory(dirName);
            using (File.Create(dirName + FILE_NAME)) { }
        } else {
            using (File.Create(filename)) { }
        }
        files.Add(filename);
    }
    //Adding 1000 Directories didn't change File Performance
    /*for (int i = 0; i < 1000; i++) {
        string filename = dir + Guid.NewGuid();
        Directory.CreateDirectory(filename + "D");
    }*/
    Console.WriteLine("measure...");
    var r = new Random();
    var sw = new Stopwatch();
    sw.Start();
    int len = 0;
    int count = 0;
    while (sw.ElapsedMilliseconds < 5000) {
        string filename = files[r.Next(files.Count)];
        string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename);
        len += text.Length;
        count++;
    }
    Console.WriteLine("{0} File Ops/sec ", count / 5);
    return numFilesInDir; 
}

十万应该没问题。
我（轶事）看到人们有数百万个文件的问题，我自己也有问题，资源管理器只是不知道如何计算过去60多万个文件，但NTFS应该是好的卷你说。
如果你想知道，技术上（我希望 * 理论上 *）的最大文件数量是：4,294,967,295

对于本地访问，大量的目录/文件似乎不是问题。但是，如果您通过网络访问它，在几百个之后会有明显的性能下降（特别是从Vista机器访问时（XP到Windows Server w/NTFS似乎在这方面运行得更快））。

当你创建一个有N个条目的文件夹时，你在文件系统级别创建了一个有N个条目的列表。这个列表是一个系统范围的共享数据结构。如果你开始通过添加/删除条目来不断修改这个列表，我预计至少会有一些共享数据上的锁争用。这种争用-理论上 * -会对性能产生负面影响。
对于只读的情况下，我无法想象有任何原因的性能下降的目录与大量的条目。

我有真实的经验，大约10万个文件（每个几MB）在NTFS上的一个目录，同时复制一个在线库。
用Explorer或7-zip打开目录大约需要15分钟。
用winhttrack写网站副本总是会卡住一段时间后。它还处理目录，包含约1 000 000个文件。我认为最糟糕的事情是，MFT只能按顺序遍历。
在ext 3上的ext 2fsd下打开同样的文件也给出了几乎相同的时间。也许移到reiserfs（不是reiser 4fs）会有所帮助。
尽量避免这种情况可能是最好的。
对于你自己的程序来说，使用blob w/o任何文件系统都是有益的，这就是Facebook存储照片的方式。

除了NTFS之外，托管文件系统的服务器和[远程]使用文件系统的客户端也可以对NTFS的 * 行为 * 和 * 执行 * 产生影响。客户端通常使用SMB协议访问网络共享。每个版本的Windows Server和客户端的行为可能不同。
除此之外，SMB本身也可以进行调优。
文件服务器的性能调整|Microsoft Learn https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/