C# WinForms大对象数组的磁盘存储与快速查询方案咨询

核心场景分析 #

你的需求本质是批量遍历+条件过滤汇总，最终要生成像素级的结果图——每个像素对应一条数组条目，意味着必须对每一条数据做一次条件判断和计算。全加载内存的速度优势明显，但内存瓶颈已经显现（64位仍溢出），所以必须转向磁盘存储方案，关键是把IO和计算开销降到最低。

LiteDB的优化思路（解决速度不达预期的问题） #

LiteDB完全能适配你的场景，之前速度慢大概率是使用方式不对，调整方向如下：

• 拆分存储结构：别把整个List<CellResultPart>序列化成单个字段存，而是把每个CellResultPart作为独立文档，或者把每个栅格单元对应的List<CellResultPart>作为子文档集合。这样查询时能直接过滤单个结构体的属性，不用加载整个List后再内存过滤。
• 针对性建索引：给用户常勾选的属性（比如MaterialName、EnvironmentalClass、Location、IsExcavation）建索引，条件过滤时能快速定位符合要求的文档，减少不必要的扫描。
• 流式查询分批次处理：用LiteDB的流式API（比如Find(query, batchSize: 1000)），分批次读取数据，处理完一批就释放内存，避免一次性加载全量数据。
• 预计算派生属性：你的结构体里有很多计算属性（Depth、DepthTop、DepthBottom、IsExcavation），这些别在查询时实时算，存储时就预计算好存成字段。多占点磁盘空间换查询时的CPU和IO效率，非常划算。比如直接把IsExcavation的布尔值、Depth的计算结果存在文档里，查询时直接用。

其他可选磁盘方案 #

如果LiteDB优化后还是达不到预期，试试这两个方案：

• 自定义二进制格式文件：
  • 把CellResultPart的每个字段按固定字节顺序写入磁盘（比如double占8字节，字符串用长度前缀+UTF8字节），每个栅格单元的List<CellResultPart>记录起始位置和长度。
  • 查询时流式读取文件，逐个解析结构体，判断是否符合条件后直接汇总。这种方式IO开销极小，没有序列化反序列化的损耗，特别适合批量遍历场景。
  • 可以给常用过滤属性单独建索引文件（比如MaterialName到文件偏移量的映射），进一步缩小扫描范围。
• 内存映射文件：
  • 数据存成二进制格式，用MemoryMappedFile加载，系统会自动管理内存，只把当前需要的部分载入物理内存，避免全量加载。
  • 配合自定义索引结构，查询时通过索引定位到目标位置，直接在映射内存中读取数据，性能接近内存遍历，但内存占用完全可控。

结论 #

没必要局限于全量加载内存的方式，LiteDB是合适的选择，只要调整存储和查询逻辑就能达标；如果追求极致性能，自定义二进制格式+内存映射文件的方案更匹配你的批量遍历汇总需求。

内容的提问来源于stack exchange，提问作者gleeuwdrent