Memgraph数据库边缘索引导致查询结果错误的深度分析

问题现象

在使用Memgraph图数据库时，我们发现了一个与边缘索引相关的查询结果异常问题。当启用自动索引创建功能后，某些特定模式的查询会返回错误的结果集，而在不启用该功能时，同样的查询却能返回正确结果。

问题复现步骤

1. 正常模式下的查询： 在不启用自动索引的情况下，执行以下查询：

   MATCH (org:Org {name: 'big corp'})-[:WORKS_AT]->(person)
   OPTIONAL MATCH (person)-[:HAS_KID]->(kid)
   RETURN person.name, collect(kid.name) as kid_names;
   

   返回结果正确显示了每个员工及其子女的对应关系。

2. 启用索引后的查询： 当启动Memgraph时添加--storage-automatic-edge-type-index-creation-enabled=true参数启用边缘类型索引后，执行完全相同的查询，返回结果出现了异常——某些没有子女的员工被错误地关联到了其他员工的子女数据上。

技术分析

查询计划对比

通过分析查询执行计划，我们发现关键差异在于边缘索引的使用方式：

1. 无索引时的查询计划： 系统采用常规的扫描和扩展操作来获取相关节点和关系，保持了查询上下文的正确性。

2. 启用索引后的查询计划： 查询优化器选择了ScanAllByEdgeType操作来利用边缘索引加速查询，但该操作未能正确维护已绑定的变量上下文，导致结果关联错误。

根本原因

问题的核心在于ScanAllByEdgeType操作实现上的缺陷：

• 该操作在扫描特定边缘类型时，没有正确验证扫描到的边缘起点是否与查询上下文中已绑定的person节点匹配
• 导致边缘索引扫描返回了所有符合边缘类型的记录，而不考虑这些记录是否确实属于当前查询上下文中特定的person节点

解决方案建议

针对这个问题，我们建议两种可能的修复方案：

1. 查询计划优化方案： 在ScanAllByEdgeType操作前添加过滤操作，确保扫描结果与已绑定的变量匹配。修改后的查询计划应类似：

   | " | * Filter Generic {person, anon4}"                    
   | " | * ScanAllByEdgeType (kid)<-[anon3:HAS_KID]-(anon4)"  
   

2. 游标实现修复方案： 修改ScanAllByEdgeCursor::Pull方法的实现，在内部加入对已绑定变量的验证逻辑，确保只返回与查询上下文匹配的记录。

影响评估

这个问题属于中等严重性级别(S3)的缺陷，具有以下特点：

• 影响范围：特定查询模式下的结果准确性
• 触发条件：启用边缘类型索引且查询包含OPTIONAL MATCH子句
• 频率：每次符合条件时都会重现

最佳实践建议

在Memgraph修复此问题前，建议用户：

1. 对于包含OPTIONAL MATCH的复杂查询，暂时禁用边缘类型索引
2. 在关键业务查询上增加结果验证逻辑
3. 监控查询结果的一致性，特别是在启用/禁用索引配置变更后

总结

这个案例展示了数据库索引实现中的微妙问题——即使是最基础的优化技术，如果实现不完善，也可能导致严重的正确性问题。Memgraph团队需要仔细审视边缘索引的实现，确保其在加速查询的同时不损害结果的准确性。对于用户而言，这也提醒我们在使用任何数据库的高级特性时，都需要进行充分的结果验证。