导入多类型节点及关系的图数据最优方案与性能优化咨询

• 先修正索引使用错误：你当前OPTIONAL MATCH (target1 { id: target1Id })的写法未指定节点标签，而绝大多数图数据库的索引都是标签+属性绑定生效的，无标签的匹配会触发全库扫描，自然无法用到你创建的索引。修改为OPTIONAL MATCH (t:目标标签 {id: $id})的格式即可触发索引命中，查询效率会有量级提升。
• 放弃手动拼接多MATCH/CREATE的方案：这种写法每次生成的查询结构都不相同，数据库无法缓存执行计划，每次查询都要重新生成执行计划，额外开销远高于参数化的UNWIND方案，继续使用参数化UNWIND的批量写法即可。
• 调整数据处理逻辑与批次大小：
  • 不要在Cypher查询内做嵌套JSON的结构解析，先在应用层将你提供的嵌套JSON拍平，拆分为独立的「节点列表」「关系列表」两类参数，再传入查询做UNWIND处理，数据库内的结构运算效率远低于应用层。
  • 调整批次大小，单批次内节点操作控制在1000_{3000条，关系操作控制在2000}5000条即可，批次过大会导致事务内存占用过高、提交耗时拉长，批次过小会导致事务创建开销占比过高。
• 按操作类型分组执行查询：不要在一个查询内混合多种类型节点、多种类型关系的写入，将同标签节点的创建、同类型关系的创建拆分为独立的查询执行，数据库查询优化器可以生成更高效的执行计划。
• 临时调整导入阶段的配置：
  • 导入前仅保留MATCH查询必需的索引/约束，非查询用的索引、非必要的属性约束待全量数据导入完成后再创建，可减少写入时的索引更新开销。
  • 调大数据库的页缓存与堆内存配置，确保索引、活跃数据可以全部载入内存，避免磁盘IO成为瓶颈。如果对数据一致性要求不高，可临时开启异步刷盘配置，进一步提升写入速度。

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