📚 课程目录第4章 Neo4j进阶

Neo4j 进阶：关系创建、索引约束与性能调优

这一章咱们要聊点更实在的东西。关系创建、索引约束和性能调优，说实话，这三大块才是把 Neo4j 从“玩具”变成“生产工具”的关键。我当年第一个药物知识图谱项目，就因为没搞懂索引和关系方向，查询慢得让人崩溃。嗯，后来踩过的坑，今天咱们一次性填平。

本章核心要点：

• 带属性的关系创建与方向控制

• 索引与唯一约束的正确用法

• 查询计划分析与写入性能调优

关系创建：不只是连一条线

很多人觉得创建关系不就是 MATCH (a) MATCH (b) CREATE (a)-[:REL]->(b) 吗？其实没那么简单。你想想看，药物和靶点之间的关系，起码要有置信度、来源文献、实验类型这些属性。光秃秃一条边，那就是个空壳。

我带团队做药物 KG 时，一开始用了无属性关系，后来要算“药物-靶点置信度评分”，发现得把属性塞在关系上重新导入，那叫一个痛苦。所以我建议，一开始就养成带属性关系的习惯。

关系属性优势：
• 避免创建大量中间节点，保持图结构简洁
• Cypher 中直接用 r.score 访问，无需 JOIN
• 适合存储轻量级关联元数据（权重、时间戳、来源）

看个例子，创建带属性的 INTERACTS_WITH 关系：

MATCH (d:Drug {id: "DB00001"})
MATCH (t:Target {id: "T0001"})
CREATE (d)-[r:INTERACTS_WITH {
    confidence: 0.92,
    source: "DrugBank",
    evidence_type: "binding_assay",
    created_at: datetime()
}]->(t)
RETURN r

另一个我常踩的坑是关系方向。药物作用于靶点，方向是从 Drug 到 Target。但数据库能让你双向查，不代表建模时就能乱来。保持语义一致性，以后做图算法（比如 PageRank、节点相似度）才不会出幺蛾子。

创建多条关系时别逐条执行，用批量插入：

UNWIND [
  {drug_id: "DB00001", target_id: "T0001", conf: 0.90},
  {drug_id: "DB00001", target_id: "T0002", conf: 0.85},
  {drug_id: "DB00002", target_id: "T0001", conf: 0.78}
] AS pair
MATCH (d:Drug {id: pair.drug_id})
MATCH (t:Target {id: pair.target_id})
CREATE (d)-[:INTERACTS_WITH {confidence: pair.conf}]->(t)

警告：批量创建时确保节点已存在，否则 MATCH 不到会跳过整行（静默失败）。我曾吃过这个亏，导致 20% 的关系没写进去。

索引与约束：性能的生命线

你要问我 Neo4j 性能优化第一要义是什么？索引。没有索引的全图扫描，就像在 10 万本药典里一页页翻。我有个教训：早期项目不加索引，一个简单的 MATCH (d:Drug {name: "阿司匹林"}) 跑了 8 秒。加了索引后，8 毫秒搞定。

创建索引很简单，但得选对字段。通常对查询频繁的标签+属性组合创建：

CREATE INDEX drug_id_index FOR (d:Drug) ON (d.id)
CREATE INDEX target_name_index FOR (t:Target) ON (t.name)
// 复合索引（多属性）
CREATE INDEX drug_name_mol_index FOR (d:Drug) ON (d.name, d.molecular_weight)

约束比索引更强大。唯一约束在保证数据质量的同时，自动创建索引。我用唯一约束来防止重复节点：

CREATE CONSTRAINT unique_drug_id FOR (d:Drug) REQUIRE d.id IS UNIQUE
CREATE CONSTRAINT unique_target_name FOR (t:Target) REQUIRE t.name IS UNIQUE

还有个容易被忽视的 节点键约束，适合多属性复合唯一：

CREATE CONSTRAINT drug_name_and_source 
  FOR (d:Drug) REQUIRE (d.name, d.source) IS NODE KEY

这个约束强制 (name, source) 组合唯一，并且自动创建复合索引。如果你有来自不同数据库的同名药物，这个约束能防止冲突。

类型	作用	索引自动创建	适用场景
普通索引	加速查询	否（索引本身就是索引）	非唯一字段的频繁查询
唯一约束	保证字段唯一性	是	主键、业务唯一标识
节点键约束	复合字段唯一	是（复合索引）	联合业务键

个人习惯：我在导入数据前先建好所有约束，这样重复数据会直接报错，而不是写进去再清洗。报错信息里会明确告诉你是哪条数据冲突，省去很多排查时间。

性能调优：让查询飞起来

好，关系建好了，索引也有了，但查询还是慢？这时候就得拿出真正的调优手段了。我常用的三板斧：配置参数、查询计划分析、避免反模式。

配置参数调优

Neo4j 的 JVM 堆内存和页面缓存是最关键的。对于药物 KG 这种中等规模（千万节点级别），我建议：

# neo4j.conf
dbms.memory.heap.initial_size=4G
dbms.memory.heap.max_size=8G
dbms.memory.pagecache.size=8G
dbms.memory.off_heap.max_size=2G

页面缓存要大到能装下整个图数据库的索引文件和热节点数据。怎么知道多大？用 MATCH (n) RETURN count(n) 测试时留意磁盘 IO，如果频繁触发 swap 就说明缓存太小。

查询计划分析

用 EXPLAIN 看预估计划，用 PROFILE 看实际执行。我一般先跑 EXPLAIN，确认没走全图扫描，再用 PROFILE 定位瓶颈。

PROFILE
MATCH (d:Drug {id: "DB00001"})-[r:INTERACTS_WITH]->(t:Target)
RETURN t.name, r.confidence

输出结果里重点关注 NodeByLabelScan 和 Filter 算子。如果出现大量 rows 被 filter 掉，说明索引没命中或者谓词不够精确。

我曾经遇到一个查询，EXPLAIN 显示走了索引，但 PROFILE 发现实际还是扫了 10 万行。后来发现是 Cypher 里对属性用了 toString() 函数，导致索引失效。嗯，记住：索引只对原始值生效，别在条件里包装函数。

避免的反模式

避免深度可变路径不加限制：MATCH (a)-[*]-(b) 会爆。必须加长度范围，比如 [*1..4]。
避免在 WHERE 里用 NOT：WHERE NOT (d)-[:INTERACTS_WITH]->(:Target) 很难走索引，先 OPTIONAL MATCH 再过滤更高效。
避免大量 MERGE 操作：MERGE 内部要检查存在性，并发写入时容易死锁。批量导入建议用 CREATE + 唯一约束兜底。

调优检查清单：

✓ 所有查询键字段都有索引（唯一约束自带索引）

✓ 查询条件中不包裹函数

✓ 可变路径指定最小最大长度

✓ 页面缓存至少覆盖热数据

✓ 使用 EXPLAIN 和 PROFILE 定期审查慢查询

最后提一嘴，Neo4j 的写入性能受事务大小影响。我习惯每 1000 条关系提交一个事务，比逐条快 10 倍，也不会爆事务日志。

:auto USING PERIODIC COMMIT 1000
LOAD CSV FROM "file:///drug_target_rels.csv" AS row
MATCH (d:Drug {id: row[0]})
MATCH (t:Target {id: row[1]})
CREATE (d)-[:INTERACTS_WITH {confidence: toFloat(row[2])}]->(t)

这一章的内容，说白了就是：关系创建别偷懒，属性带上；索引约束提前建，后患少；性能调优不急，先从计划和配置入手。把这些基本功打扎实了，后面做 PyG 特征提取才有底气。