FAT，在检索文件时优化性能

如果直接访问文件，那么性能不会下降。如果您在磁盘上搜索特定的文件，将它们存储在文件夹中会更快。通过这种方式，文件夹将模拟数据库索引。但正如@blow所提到的，你为什么不使用类似Sqlite的东西呢？

当您retrieve a file by filename时，您很可能会在包含该文件的目录中进行线性搜索，您会跳过所有目录条目，直到找到与给定文件名匹配的条目。

如果你每次都对每个文件进行搜索，那么这个搜索操作可能会很慢，因为目录中有很多文件，读取速度很慢（如果你的CPU很慢，你会损失更多）。

您可能需要构建某种索引，即按文件名排序的filename+location对的紧凑数组，可以将其保存在内存中，以便在不重读目录项的情况下快速查找文件。

如果有固定数量的文件，并且它们具有相同的长度或填充到相同的长度，那么事情可以大大简化。在这种情况下，你不需要任何搜索，因为你可以直接从文件名计算每个文件的位置，当然，前提是文件的顺序是固定的。

在这种情况下，FAT1x和FAT32之间唯一的实际差异是文件分配表的大小，即一组链表/链，它告诉哪些集群是空闲的或被文件/目录数据占用，告诉哪个集群是文件/目录中给定集群之后的下一个集群。在FAT32中，集群链元素是32位的，是FAT16的2倍。如果使用的集群数量较少（小于~64K），则在遍历集群链时，从FAT32读取的数据将是FAT16的两倍。此外，如果磁盘上有许多集群，在FAT32上找到一个可用集群（当您创建一个新文件/dir或扩展现有文件/dir时）可能会很慢（FAT32 AFAIR上可能有2^28个集群，而FAT16中有2^16个集群）。你不想每次从FAT开始就开始搜索一个免费的集群。你想在某个地方保留一个指针，指向你停止搜索的最后一个地方和下一次搜索的地方，然后当你到达FAT结束时转到FAT的开始。

将它们拆分到目录中（拆分编号取决于集群大小），如果可以的话，不要使用LFN（LongFileName），因为这会减慢操作速度。我也从事装饰系统的工作。我不必像你一样访问1000个文件，但我避免了LFN（尤其是出于版税原因）。