Neo4j非唯一索引与唯一约束性能悬殊问题排查

这是个非常典型的Neo4j索引/约束性能差异问题，咱们直接从核心点拆解：

1. 唯一约束≠普通非唯一索引 #

当你创建唯一约束时，Neo4j不仅会强制数据唯一性，还会自动创建一个优化过的唯一索引——这个索引的底层实现和普通非唯一索引有本质区别：

• 普通非唯一索引允许同一个键关联多个节点，存储结构上需要处理多节点的映射；
• 唯一索引从设计上就保证每个键仅对应0或1个节点，存储结构做了针对性优化，查询时可以直接定位到目标节点，不需要考虑多节点匹配的情况。

2. 查询计划的核心差异：NodeIndexSeek vs NodeUniqueIndexSeek #

从你用PROFILE看到的两种操作，就能直接解释性能差距：

• NodeIndexSeek（非唯一索引）：即使你的实际数据中没有重复值，数据库也不知道这一点。它会按照"可能存在多个匹配节点"的逻辑执行：先查找索引中匹配的所有条目，再逐个遍历对应的节点，甚至可能需要额外的过滤步骤来确保结果符合预期。这就导致每个查询都要做冗余的遍历和检查，在25万节点的库中，这种开销会被放大，直接拉低TPS。
• NodeUniqueIndexSeek（唯一约束/索引）：数据库通过唯一约束的元数据明确知道，这个查询最多只会返回1个节点。所以它会直接通过索引定位到唯一匹配的节点（或者确定没有匹配），没有任何额外的遍历或检查步骤。整个查询路径极度精简，事务执行时间被压缩到极致，TPS自然暴涨到7000。

3. 事务层面的连锁反应 #

你的场景是执行简单查询，每个事务的核心操作就是定位节点。当用唯一索引时，每个事务的执行路径几乎是"索引定位→返回结果"，没有多余的IO和CPU消耗；而非唯一索引的事务需要"索引扫描→节点遍历→结果校验"，每个步骤都要占用资源，导致每秒能处理的事务数（TPS）只有15。

总结一下：唯一约束带来的不仅是数据一致性保障，更重要的是让数据库可以用最优的查询计划执行单节点查找，彻底避免了非唯一索引的冗余操作，这就是性能差距的根源。

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