开篇：一个根深蒂固的联想

每次有人提"知识图谱"，紧接着的一句话几乎一定是：

“那我们用 Neo4j 吧。”

好像知识图谱和图数据库是绑定的。上了知识图谱就必须上图数据库，不上图数据库就不算知识图谱。

这是一个被混淆了十年的概念。

知识图谱是"怎么组织数据"的决策，图数据库是"存在哪里"的选型。 它们是两个正交的维度，可以自由组合。

本文做两件事：

1. 用一个 SQL 例子证明：知识图谱可以存在 MySQL 里，跑得好好的
2. 给出"什么时候才真正需要图数据库"的判断标准

读完你能：分清"数据组织方式"和"存储介质"，不再被"上了知识图谱就得用图数据库"带偏。

---

一、知识图谱 vs 图数据库：两个正交维度

所有"存记忆/存知识"的方案，都可以从两个正交维度去看：

维度 1：存什么形态（数据组织方式）
  - 原始消息（ChatMessage，日志形态）
  - 结构化条目（有 type / subject / status 等元数据）
  - 向量嵌入（embedding，一串数字）
  - 知识图谱（节点 + 边，有向图）

维度 2：放哪里（存储介质）
  - 内存（Map，进程内）
  - 文件（JSONL / SQLite）
  - 关系型数据库（MySQL / PostgreSQL）
  - 内存型数据库（Redis）
  - 向量数据库（Milvus / pgvector / Pinecone）
  - 图数据库（Neo4j / Graphiti / Amazon Neptune）

知识图谱落在维度 1，图数据库落在维度 2。

知识图谱是一种"用图的方式组织数据"的形态选择–实体是节点，关系是边：

(用户A) --[对花生过敏]--> (花生)
(用户A) --[亲属]--> (用户B)
(用户B) --[对坚果过敏]--> (坚果)
(花生) --[属于]--> (坚果类)

这是"怎么组织数据"的问题，跟"存在哪"完全无关。

图数据库是一种"专门存图结构、做图查询"的存储介质–它原生存节点和边，查询用 Cypher 这种图遍历语言。

它们可以自由组合。 知识图谱可以存在图数据库里，也可以不存在。

---

二、知识图谱可以存在 MySQL 里

这是最反直觉但最重要的一点。用两张表就能存知识图谱：

-- 节点表
CREATE TABLE kg_node (
  id      VARCHAR PRIMARY KEY,
  type    VARCHAR,         -- User / Food / Category
  props   JSON             -- 其他属性
);

-- 边表
CREATE TABLE kg_edge (
  from_id VARCHAR,          -- 起点
  to_id   VARCHAR,          -- 终点
  type    VARCHAR,         -- RELATIVE_OF / ALLERGIC_TO / BELONGS_TO
  props   JSON             -- 边的属性（什么时候说的、谁说的）
);

查"用户亲属的过敏史"，用 SQL JOIN 模拟图遍历：

SELECT f.props->>'$.content'
FROM kg_edge e1                                    -- 用户-亲属
JOIN kg_edge e2 ON e1.to_id = e2.from_id           -- 亲属-事实
JOIN kg_node f ON e2.to_id = f.id                  -- 事实内容
WHERE e1.from_id = 'userA'
  AND e1.type = 'RELATIVE_OF'
  AND e2.type = 'SAID'
  AND f.props->>'$.content' LIKE '%过敏%';

这是知识图谱–节点 + 边组织数据，完整表达了"用户-亲属-事实"的关联结构。

但这不是图数据库–存在 MySQL 里，查询用 SQL JOIN，没有 Neo4j 什么事。

而且它能跑。大多数企业知识图谱就是这么存的，没毛病。

---

三、知识图谱可以存在的五种介质

不只是 MySQL。知识图谱可以落在很多种介质里：

介质	怎么存知识图谱	怎么查	适合
图数据库	原生节点+边	Cypher 图遍历	深度遍历、关系推理
关系型 DB	nodes 表 + edges 表	SQL JOIN 模拟图遍历	大多数企业知识图谱
内存	对象引用 + 邻接表	代码遍历	小规模图谱
文件	JSON / RDF / Turtle	加载后遍历	离线知识图谱导出
向量 DB	每个节点存一个 embedding	向量相似	不算真正的图谱查询

最后一行要特别注意：把知识图谱的节点存在向量数据库里，查询只能做"找相似节点"，做不了"顺着边推理"（"用户亲属的过敏史"查不出来）。向量数据库不是知识图谱的正确存储介质–这是个常见的误用。

---

四、什么时候才真正需要图数据库

知识图谱存在 MySQL 里能跑，但有一个会爆炸的问题：图遍历深度变深时，SQL JOIN 的性能急剧下降。

1 跳：用户 -> 他说过的事实
     -> 1 次 JOIN，毫秒级

2 跳：用户 -> 亲属 -> 亲属说过的事实
     -> 2 次 JOIN，毫秒级

3 跳：用户 -> 亲属 -> 亲属的同事 -> 同事说过的事实
     -> 3 次 JOIN，开始慢

5 跳以上：多表 JOIN 爆炸
     -> MySQL 扛不住
     -> 这时候需要图数据库

为什么？关系型 DB 的 JOIN 是笛卡尔积：每次 JOIN 都要把两表的行数相乘。5 跳意味着 5 次 JOIN，复杂度是 O(表大小^5)–百万行表的 5 次方是 10^30，宇宙毁灭都查不完。

图数据库用邻接表索引，图遍历的复杂度是 O(分支因子^深度)，跟表大小无关，只跟图的局部结构有关。加上索引优化，5 跳查询实测毫秒级。

Neo4j 查 5 跳：O(分支因子^深度)，索引优化后毫秒级
MySQL 查 5 跳：5 次 JOIN，O(表大小^5)，爆炸

这就是图数据库存在的唯一理由：深度遍历。

浅度遍历的知识图谱不需要图数据库（关系型 DB 够），深度遍历的才需要。

---

五、知识图谱选型判断标准：你的查询要几跳

要不要上图数据库，看你的核心查询的遍历深度：

你的知识图谱查询要几跳？

  1 跳：用户 -> 他说过的事实
     -> 关系型 DB 的 1 次 JOIN，毫秒级，完全够

  2 跳：用户 -> 亲属 -> 亲属的事实
     -> 关系型 DB 的 2 次 JOIN，毫秒级，够

  3 跳：用户 -> 亲属 -> 同事 -> 同事的事实
     -> 关系型 DB 的 3 次 JOIN，开始慢
     -> 如果查询频繁，考虑图数据库

  5 跳+：跨多实体的复杂关联
     -> 关系型 DB 爆炸
     -> 必须用图数据库

大多数企业知识图谱的查询是 1-2 跳，关系型 DB 完全够。不要为了"看起来高级"就上 Neo4j–运维成本、学习曲线、生态成熟度都是代价。

---

六、Agent Memory 场景判断

回到 AI Agent 的记忆系统。要不要知识图谱、要不要图数据库，按场景判断：

场景	要不要知识图谱	要不要图数据库
存"用户对花生过敏"	不需要（一条结构化条目够）	不需要
存"用户说过 X，后来改口说 Y"	不需要（标记取代链够）	不需要
查"用户亲属的过敏史"	需要（跨实体关联）	看遍历深度，浅的话关系 DB 也行
查"这个 PR 沉寂 3 天了，关联 CI 失败 + 负责人请假"	需要（多跳推理）	大概率需要
查"3 个月前这条事实当时对不对"	需要（时序推理）	Zep/Graphiti 用图做双时间轴

双时间轴：图数据库的另一个用武之地

最后那个场景"3 个月前这条事实当时对不对"值得展开。这是图数据库（特别是 Zep/Graphiti）的另一个杀手级特性：双时间轴。

validFrom / validTo   事实在现实世界中的有效期
  "对花生过敏"   validFrom=T1, validTo=T3   （T1 到 T3 期间为真）
  "不过敏"       validFrom=T3, validTo=null （T3 之后为真）

recordedAt            系统什么时候录入这条记忆
  fact1.recordedAt = T1   （T1 时录入）
  fact2.recordedAt = T3   （T3 时录入）

关系型 DB 的记忆只有"录入时间"，回答不了"上周三时用户对花生过敏吗"。图数据库通过边的 validFrom/validTo 能回答这种时序问题–查 validFrom <= 周三 < validTo 的事实。

如果你的 Agent 需要时序推理（“当时知道什么、什么时候知道的”），图数据库是有价值的选择。

---

七、总结

知识图谱     = "用图组织数据"的形态选择（维度 1）
图数据库     = "专门存图、查图"的存储介质（维度 2）

知识图谱 ≠ 图数据库

知识图谱可以存在：图 DB / 关系 DB / 内存 / 文件
图数据库专门存：知识图谱（节点 + 边）

选不选用知识图谱：看你要不要"关系推理"
选不选用图数据库：看遍历深度，浅的用关系 DB 够，深的才需要图 DB

三句话收束：

1. 知识图谱是设计决策（怎么组织数据），图数据库是工程选型（存在哪里）。 它们正交，可以自由组合。
2. 知识图谱不一定要用图数据库。 两张表 + SQL JOIN 就能存知识图谱，大多数企业就是这么做的。
3. 图数据库的唯一理由是深度遍历。 浅度遍历用关系型 DB 够，深度遍历（5 跳+）才需要图 DB。时序推理是另一个加分项。

下次有人提"知识图谱"，先问他：“你的查询要几跳？” 再决定上不上图数据库。

---