第 2 讲：为什么你的 Excel 解决不了的问题，知识图谱能解决？
“💡 关注我们，不错过每一讲本系列正在从零开始，手把手教你搭建一个可工业落地的知识图谱。 从原始文档到智能问答，全链路无跳步讲解。 如果你正在为复杂数据关联问题头疼，这一讲就是为你准备的。
一、引入：昨天讲了"是什么"，今天讲"为什么"
上一讲我们搞清楚了知识图谱最朴素的定义：一张存了"实体"和"关系"的图，用来回答复杂关联问题。我们也用"液压泵温度过高"的三句话，搭出了第一张微型图。
但你可能还是会有疑问：听起来是挺好的，可我手里的数据大部分都躺在 Excel 和数据库里，SQL 写得溜溜的，知识图谱到底能帮我解决什么 Excel 解决不了的问题？
这就是今天要回答的核心问题。我们不堆术语，就用 10 个你工作中可能真实遇到的场景，让你直观地感受到：当"关系"本身成为问题的一部分时，表格就会力不从心，而图才刚刚开始发力。
二、概念讲解：关系型数据库的天花板在哪里？
1. Excel 和 SQL 擅长什么？
在讨论"图能做什么"之前，我们得先承认表格的强大。表格是人类处理结构化数据最伟大的发明，没有之一。
它极其擅长回答这一类问题：
- "过去 6 个月，液压泵一共坏了多少次？"——一条
SELECT COUNT(*) 搞定。 - "上个月维修成本最高的三台设备是哪三台？"——一条
GROUP BY 排序搞定。 - "某型号轴承的库存还剩多少？"——一条带
WHERE 的查询搞定。
这些问题有个共同特点：**它们都在问"某一行/某几行的属性是什么"**。表格用"行 × 列"这种二维结构，把每一行当一个"对象"，每个对象的属性清清楚楚写在列里——这是表格最舒服的姿势。
2. 表格的"连接天花板"
但只要你的问题开始涉及**"对象之间的关系"**，表格就开始变扭了。
假设你想知道：
“"A 设备的维修师傅 B，过去 5 年修过的所有设备里，哪些和 A 共用同一个故障原因？"
在 SQL 里，你要写多少个 JOIN？
SELECTDISTINCT d2.equipment_id
FROM maintenance_records m1
JOIN maintenance_records m2 ON m1.worker_id = m2.worker_id
JOIN equipment e1 ON m1.equipment_id = e1.id
JOIN equipment e2 ON m2.equipment_id = e2.id
JOIN fault_records f1 ON e1.id = f1.equipment_id
JOIN fault_records f2 ON e2.id = f2.equipment_id
WHERE e1.id = 'A'AND f1.cause = f2.cause;
一个 4 跳查询，已经开始让人头晕了。现实中类似的业务问题，跳数经常会到 6、7、8 跳。每多一跳，SQL 复杂度和性能都会指数级恶化。
更糟糕的是，表格里的"关系"是藏在外键里的：你得知道哪张表跟哪张表连、连到哪个字段。这种"关系元信息"分散在数据库设计的脑子里，而不是数据库本身。
3. 图数据库的根本不同
图数据库（如 Neo4j）的思路正好相反：
- 关系是一等公民：边（Edge）就是数据库的核心元素，和节点（Node）一样有属性、可查询。
- 关系是"指针"：从 A 跳到 B，再跳到 C，每一跳都是常数时间的指针访问，不会因为数据量变大而显著变慢。
- **关系有"类型"和"方向"**：你可以明确说"师傅 B 修过设备 A"，而不会和"设备 A 修过师傅 B"搞混。
所以下面这句听起来夸张但其实很实在的话你可以记住：
“SQL 的连接复杂度是 O(k)，k 是跳数；图的遍历复杂度是 O(k)，k 也是跳数——但常数项差了好几个数量级。
三、10 个真实场景：图能做什么表做不了的事
光说原理不直观。我整理了 10 个真实的应用场景，每个都用"一句人话 + 一个具体例子"展开。这些场景不限于工业制造，覆盖你能在简历上写出来的所有主流方向。
场景 1：复杂设备故障诊断
“一句人话：当设备出问题时，告诉你"可能是哪些原因"。
- 例子：数控机床报警代码 E0302，查询图谱后返回：可能原因 A（概率 35%）、B（25%）、C（15%），每条原因还附带"曾经哪些设备出过错""对应哪本手册的哪一章"。
场景 2：智能问答（FAQ 的升级版）
“一句人话：用户问一句人话，系统沿着实体关系找出答案。
- 例子：用户问"轴承 SKF-6205 适用于哪些设备？"，图谱能直接给出设备清单、所属车间、最近一次更换时间。
场景 3：个性化推荐
“一句人话：根据"用户 A 喜欢 X"以及"喜欢 X 的人也喜欢 Y"，推荐 Y。
- 例子：在企业知识库里，"看过这份《液压泵维修 SOP》的人也下载了《液压泵故障案例汇编》"。
场景 4：金融反欺诈
“一句人话：通过多层关系网找出"看起来没关系但实际是一伙的"账户。
- 例子：A 的身份证号出现在 B 的紧急联系人里，B 的手机号又出现在 C 的设备指纹里——这种 3-4 跳的隐含关系，SQL 几乎跑不动。
场景 5：药物发现与不良反应监测
“一句人话：把"药物—靶点—基因—疾病"串成一张网，发现新适应症或副作用。
- 例子：阿司匹林原本用于镇痛，通过图谱发现它对某条通路有作用，进而被发现可用于心血管疾病预防。
场景 6：军事情报分析
“一句人话：从人—事—物—地的多重关联中，找出隐藏的模式。
- 例子：情报分析中常说的"连接 7 个人的平均距离"，在图里一次查询就能完成。
场景 7：供应链风险传导分析
“一句人话：供应商 A 出问题，会传导到哪些下游企业？
- 例子：某芯片厂失火 → 它供货的 3 家 Tier1 厂商 → 它们供货的 47 家整车厂 → 涉及的具体车型和生产线——这就是经典的"供应链图谱"。
场景 8：合规与权限审查
“一句人话：谁有权限访问什么，依据是什么，是否冲突？
- 例子：员工 A 在 B 部门，但他同时加入了 C 项目组，触发了"利益冲突"规则——图谱直接给出告警链路。
场景 9：客户 360° 画像
“一句人话：把一个客户的所有行为、订单、咨询、投诉串成一张图。
- 例子：客户 X 过去 3 个月咨询过 2 次、退货 1 次、给过 1 次差评，但同时他也是高净值客户——这种"矛盾信号"在表格里很难一眼看出。
场景 10：科研辅助
“一句人话：把"论文—作者—机构—基金—关键词"串起来，找研究热点。
- 例子：最近 3 年，"图神经网络 + 药物"主题的发文量、核心作者、合作网络——一次图查询完成。
一张图总结
如果让你用一句话归纳这 10 个场景的共性，那就是：
“当"关系"本身比"属性"更重要时，表格就退居二线，图登场。
四、实战环节：用一个最小例子看表格 vs 图的差异
我们用上面"供应链风险传导"场景的一个最小子集，直观对比一下。
Step 1：场景设定
假设我们有以下实体和关系：
我们要回答一个问题：
“"如果供应商 A 失火，哪些整车厂会受影响？"
Step 2：用表格来回答
如果用 SQL 表达，你需要至少 3 张表：supplier（供应商）、tier1（一级厂商）、oem（整车厂），再加 2 张关系表：supplier_tier1 和 tier1_oem。查询类似：
-- 假设有 3 张实体表 + 2 张关系表
SELECTDISTINCT o.name
FROM supplier s
JOIN supplier_tier1 st ON s.id = st.supplier_id
JOIN tier1 t1 ON st.tier1_id = t1.id
JOIN tier1_oem t1o ON t1.id = t1o.tier1_id
JOIN oem o ON t1o.oem_id = o.id
WHERE s.name = '供应商A';
这只是 2 跳。如果要问"影响哪些具体车型"或"涉及多少产线"，跳数还要往上加。
Step 3：用图来回答（Cypher 语言）
同样的问题，在 Neo4j 的 Cypher 查询语言里写成这样：
// 第 1 讲我们已经解释过：() 表示节点，-[]-> 表示关系
// 这次只是提前让你感受一下，先不用纠结语法
MATCH (s:Supplier {name: '供应商A'})-[:SUPPLIES_TO]->(t1:Tier1)
-[:SUPPLIES_TO]->(o:OEM)
RETURN DISTINCT o.name AS affected_oem;
如果想"看完整路径"，再加一句：
MATCH path = (s:Supplier {name: '供应商A'})-[:SUPPLIES_TO*1..3]->(downstream)
RETURN path;
*1..3 的意思是"沿着 SUPPLIES_TO 这种关系，跳 1 到 3 次"。一行代码，就完成"找出所有受影响的下游"。
Step 4：对比一下
检查点
到这里，你应该能用一句话回答下面这个问题：
“"为什么图能解决表格解决不了的问题？"
参考答案：
“因为"关系"在图里是数据库的第一类公民，而在表里是被 JOIN 出来的临时结果。当问题需要沿关系多跳查询或整图分析时，图天然就比表快、简单、可维护。
五、常见坑 + 小结 + 预告
常见坑
- **"图数据库 = 性能更快"**：性能是结果，不是原因。图真正的优势是"关系的表达力"。如果你只是查"某个用户的所有订单"，SQL 不输图。
- "图数据库可以完全替代关系型数据库"：不能。表格仍然适合存"实体本身的属性"（如设备的出厂参数、维修记录的时间序列）。真正好的系统是"图 + 表"混用——表存明细事实，图存关联网络。
- "上 Neo4j 就万事大忧"：图数据库能解决查询和表达问题，但怎么把数据装进图里才是最难的——这正是本系列第三、第四、第五阶段要重点解决的。
- **"数据量小就不需要图"**：这倒是部分正确。但如果你的业务注定要"多跳查询"或"网络分析"，那怕数据量在几千到几万级别，用图仍然会比 SQL 省心得多。
本讲小结
- 关系查询一旦超过 3 跳，SQL 的复杂度和性能就会断崖式下降。
- 图数据库把"关系"作为一等公民，天然适合多跳查询、路径分析、整图模式发现。
- 10 个真实场景（故障诊断、智能问答、推荐、风控、药物发现、情报、供应链、合规、客户画像、科研）说明：图不是炫技，而是当关系成为核心问题时的最佳工具。
下一讲预告
第 3 讲，我们要画一张完整的全链路地图：从你手里那一摞乱糟糟的 PDF，到最后系统能回答"液压泵为什么会高温"——中间到底要经过哪些环节、每个环节用什么工具、我们会在第几阶段展开。**这是整个系列的"导航图"**，强烈建议先收藏这一讲，再看后面的。
“💡 关注我们，不错过每一讲本系列正在从零开始，手把手教你搭建一个可工业落地的知识图谱。 从原始文档到智能问答，全链路无跳步讲解。 下一讲开始画整条链路：9 个环节 × 5 大工具 × 7 个阶段，建议先收藏本系列，不迷路。
10个月宝宝每天需要喝多少奶粉？
