如何使用Python和Neo4j构建知识图谱【完整指南】

// 错误的写法：会忽略一些团队。具体原因如下：
MATCH (i:Incident {ref: $ref})-[:AFFECTS]->(:Service)<-[:OWNS]-(:Engineer)
      -[:MEMBER_OF]->(t:Team)<-[:MEMBER_OF]-(e:Engineer)
RETURN DISTINCT t.name AS team, e.name AS name
ORDER BY team, name

关系的唯一性：隐藏答案的陷阱

MATCH (i:Incident {ref: $ref})-[:AFFECTS]->(:Service)<-[:OWNS]-(:Engineer)-[:MEMBER_OF]->(t:Team)
WITH DISTINCT t
MATCH (t)<-[:MEMBER_OF]-(e:Engineer)
RETURN t.name AS team, e.name AS name
ORDER BY team, name

这种方法在大规模数据集上仍然有效吗？

查询结果为：返回了33名工程师的信息，发生了150次数据库访问操作，耗时4.6毫秒

变长路径及其安全保护方法

有时候，你并不知道需要经过多少个中间环节。服务之间的依赖关系就是典型的例子：支付功能依赖于身份验证，而身份验证又依赖于用户信息存储系统，因此你必须确保所有下游环节在发生故障时仍能正常运行。

MATCH (s:Service {name: $name})<-[:DEPENDS_ON*1..4]-(affected:Service)
RETURN DISTINCT affected.name

*1..4表示要追踪一到四个DEPENDS_ON关系。

对于变长路径，必须为其设定上限。因为每个中间环节都会使查询范围扩大，所以[:DEPENDS_ON*]这种写法不会对查询效率产生负面影响，而[:DEPENDS_ON*1..4]则会产生影响。在连接紧密的图中，无上限的查询会导致系统响应速度极慢，甚至无法完成查询。

必须为变长路径设定上限。在连接良好的图中，无上限的*可能会遍历数据库中的大部分数据，因此在测试数据上运行很快的查询，在生产环境中就会变得极其缓慢。这就是导致图数据库性能下降的最常见原因。

以下是每增加两个中间环节所带来的影响。以这个包含75,500个节点的数据集为例，其中某个服务拥有10,039个服务依赖关系：

可以看到，中间环节从两个增加到六个时，覆盖的服务数量增加了15倍以上，而数据库访问次数则增加了22倍。其实查询本身的逻辑并没有发生变化，只是表达方式有所不同而已。

这一点需要牢记：查询范围呈几何级数增长，相应的处理工作量也会随之增加。在连接更加紧密的图中，这种增长幅度会更大。因此，在社交图或依赖关系图中，无上限的查询可能会导致系统瞬间崩溃，而这种问题在测试环境中是不会出现的。

我故意没有给出这三种情况的具体执行时间。在这种规模的数据集上，它们的执行时间都在2到4毫秒之间，它们之间的差异只是测量误差，并非真正的性能差异。而数据库访问次数的统计结果才是可靠的比较依据，而且这种数据在你的机器上也会得到相同的结果。

你还可以查询两个节点之间的最短路径。在SQL中这是一个相当复杂的操作，但在这里只需要一行代码就可以完成：

MATCH p = shortestPath(
  (a:Engineer {email: $from})-[:MEMBER_OF|OWNS*..6]-(b:Engineer {email: $to})
)
RETURN [n IN nodes(p) | coalesce(n.name, n.email)] AS hops

这种查询方式能够揭示连接两个人的一系列关联关系。推荐系统、欺诈检测以及访问分析功能，其实都是基于这一基本查询思路衍生出来的应用。

索引的真正含义

在使用索引之前，弄清楚它的本质是非常重要的，因为本文中提到的几乎所有性能问题，最终都可以追溯到这个概念上。

想象有一本900页厚的教科书，你需要查找关于光合作用的内容。这时你有两种选择：要么从第1页开始逐页阅读直到找到相关内容，要么直接翻到书后的索引目录，找到“光合作用”这一条目，然后直接跳到第412页。

这两种方法最终都会找到相同的内容，只不过一种需要阅读整整900页，而另一种只需要翻两页而已。

数据库索引就相当于书后的索引目录。它是数据库在数据之外维护的另一种结构，它能够将某个属性值与包含该属性值的记录节点对应起来。你不需要直接查询索引，也不必告诉Cypher系统使用它——只需创建一次索引，之后在需要的时候规划器就会自动利用它。

左图展示了AllNodesScan这种查询方式：需要读取75,500个记录，其中只有1条记录包含所需信息，其余75,499条记录都需要被读取。右图则展示了NodeUniqueIndexSeek的方式：只需要读取两次数据，一次是索引条目，另一次才是目标页面的内容。

这个示例还展示了本手册后面会提到的一个测试结果：在包含75,500个记录的数据集上，使用NodeUniqueIndexSeek方法后，数据库的访问次数从151,002次减少到了3次。需要记住的是，你根本不需要告诉Cypher系统使用索引——只需创建一次索引，之后在需要的时候它就会自动利用它。

下面是在包含75,500个记录的数据集上，用三种不同的方式进行的相同查询操作。这三种方法最终都找到了同一位工程师的信息，也得到了相同的结果。不同的是，数据库为完成这些查询所需要付出的努力程度。

第一种方式：不使用标签，也不使用索引。

PROFILE MATCH (n) WHERE n.email = 'eng25000@example.com' RETURN n.name

操作方式                描述                                      执行时间  记录数  数据库访问次数
ProduceResults      `n.name`                     3775        1        0
  Projection        n.name AS `n.name`           3775        1        1
    Filter          n.email = $autostring_0      3775        1    75500
      AllNodesScan  n                           75500    75500    75501

AllNodesScan这种方式意味着数据库需要读取所有的75,500条记录，包括那些可能根本不存在电子邮件属性的服务、团队或事件信息。之后Filter操作才会检查这些记录中的电子邮件字段。最终：数据库共进行了151,002次访问才找到了目标记录。

第二种方式：使用了标签，但仍然没有使用索引。

PROFILE MATCH (e:Engineer) WHERE e.email = 'eng25000@example.com' RETURN e.name

操作方式                    详细信息                        执行次数    访问次数   数据库访问次数
ProduceResults         `e.name`                  2500        1        0
  Projection           e.name AS `e.name`        2500        1        1
    Filter             e.email = $autostring_0   2500        1    50000
      NodeByLabelScan  e:Engineer               50000    50000    50001

NodeByLabelScan这种方式更好。它只读取那50,000个工程师的相关信息，而不是全部75,500个节点的数据。不过，它仍然需要读取每一个节点的信息。总访问次数：100,002次。标签的作用虽然缩小了搜索范围，但并没有让我们能够直接找到目标数据。

CREATE CONSTRAINT engineer_email IF NOT EXISTS
FOR (e:Engineer) REQUIRE e.email IS UNIQUE

PROFILE MATCH (e:Engineer) WHERE e.email = 'eng25000@example.com' RETURN e.name

操作方式                 详细信息                                        执行次数    访问次数   数据库访问次数
ProduceResults           `e.name`                                         1      1        0
  Projection             e.name AS `e.name`                               1      1        1
    NodeUniqueIndexSeek  UNIQUE e:Engineer(email) WHERE email = $auto      1      1        2

在这里，我们用三种不同的方式来查找同一个工程师的信息。在包含75,500个节点的图中，我们需要从这50,000个工程师中找到目标对象。这些操作是在Neo4j 5.26.29 Community版本上使用PROFILE命令进行的。三种方法得出的结果都是相同的。不同的是处理数据的方式：一种是读取所有具有该标签的节点，另一种是通过属性来缩小搜索范围，而第三种则是直接利用索引来快速定位目标数据。

第三种方法的效率是151,000种方法的1/151,000，这就是为什么在表格中会明确指出使用索引带来的效果：

在我的机器上，不使用索引时查询时间为35.4毫秒，而使用索引后查询时间仅为4.0毫秒，速度提高了大约9倍。

你不会得到9这样的结果。当我从一个新的代码环境中再次运行这个相同的测试时，对相同数据进行的相同查询，其执行速度实际上是17倍快，而不是9倍。两次测试中，数据库访问次数也是完全相同的：分别是100,002次和3次。

这种对比恰恰说明了问题的关键所在。数据库访问次数是由你的数据和查询语句决定的，因此每次测试的结果都应该是一致的；而执行速度则取决于你使用的机器性能，所以两次测试的结果可能会有所不同。当你比较两种不同的查询编写方式时，应该关注的是它们对应的数据库访问次数。

Neo4j提供的索引类型

大多数教程都只介绍了一种索引类型，然后就不再深入讲解了。但实际上Neo4j 5提供了六种不同的索引类型，如果选择了错误的索引类型，其效果相当于根本没有使用任何索引，因为查询优化器会自动忽略那些无法满足你的查询条件的索引。

人们常常会疑惑的是“范围索引”和“文本索引”之间的区别。范围索引能够很好地处理STARTS WITH操作，因为具有相同前缀的名称在排序后的结果中会相邻排列，就像“photosynthesis”和“photosphere”在书籍目录中是相邻的条目一样。然而，文本索引无法用于CONTAINS或ENDS WITH操作，因为你要搜索的内容可能位于字符串值的任意位置，而排序后的结构无法帮助你缩小搜索范围——而这正是文本索引存在的意义所在。

Neo4j提供了六种不同的索引类型，每种类型都有其特定的适用场景。如果选择了错误的索引类型，其效果相当于根本没有使用任何索引，因为查询优化器会自动忽略那些无法满足查询条件的索引，而你却无从察觉这一情况。

如果你完全不指定使用哪种索引类型，系统会默认使用“范围索引”，而对于绝大多数情况来说，这种设置已经是非常合适的选择了：

CREATE INDEX service_tier IF NOT EXISTS FOR (s:Service) ON (s.tier)

你也可以同时为多个属性创建索引，这种索引被称为复合索引：

CREATE INDEX service_tier_name IF NOT EXISTS FOR (s:Service) ON (s.tier, s.name)

复合索引与两个独立的索引不同。它是一个整体结构：首先按照层级进行排序，然后在同一层内再按照名称进行排序，就像按城市和姓氏对电话簿进行排序一样。当你需要同时根据这两个条件进行过滤时，复合索引非常有用；但如果你只使用第二个条件进行过滤，那么复合索引就毫无用处了，因为在这种情况下，你无法在仅按城市分类的电话簿中查找特定的姓氏。

复合索引涵盖了多个属性的组合，而这些属性的排序顺序决定了它能够服务于哪些查询。如果只根据第一个属性进行过滤，那么就可以使用这个复合索引；但如果只根据第二个属性进行过滤，就无法使用它。

关系也可以被创建为索引，使用的语法与创建普通属性索引的语法相同，只需在字段名前加上“r:”即可：

CREATE INDEX owns_since IF NOT EXISTS FOR ()-[r:OWNS]-() ON (r.since)

要查看自己创建了哪些索引，可以执行以下命令：

SHOW INDEXES

为什么你的索引没有被使用

如果某个索引存在但却从未被使用过，那确实是一件非常令人沮丧的事情，因为表面上一切看起来都是正确的。造成这种情况的常见原因有四种，而PROFILE命令可以帮助你确定具体是哪种原因导致了这个问题。

1. 你创建的索引与实际用于过滤的数据属性不同。例如，如果为email字段创建了索引，那么对于那些根据name字段进行过滤的查询来说，这个索引根本无法发挥作用。

2. 你的查询条件无法使用该类型的索引。比如，使用CONTAINS操作符对范围索引进行查询时，即使索引确实存在，查询引擎也会判断它无法提供帮助。

3. 你将某个属性放在了函数内部。例如，如果写成WHERE toLower(e.email) = 'x'这样的语句，那么索引就无法被使用，因为索引中存储的是原始值，而不是小写后的值。应该将属性的值进行规范化处理后再创建索引。

4. 你没有为该节点指定标签。索引是建立在节点标签基础上的。如果MATCH (n) WHERE n.email = ...这样的查询语句没有可用的标签，那么系统就会扫描数据库中的所有节点，从而导致性能下降。

约束条件，以及会让你陷入困境的因素

索引可以使查找操作变得快速；而约束条件则是一些必须严格遵守的规则。它们的作用不同，但之所以会被一起讨论，是因为在Neo4j中，其中一种机制会在无形中实现另一种机制的功能。

每次执行MERGE操作时，系统都必须检查是否存在具有相同标签的节点。如果没有索引，这种检查就需要遍历所有带有该标签的节点。

当节点数量仅为一千个时，这种检查不会对性能产生明显影响；但当节点数量达到十万个时，导入操作会变得非常缓慢，而且原因并不容易察觉，因为并没有任何功能出现故障——只是在进行大量不必要的处理而已。

对于那些用于进行合并操作的属性，应该为其设置唯一性约束。这样既能确保数据的正确性，同时系统也会自动生成相应的索引。

下面我们展示了在设置唯一性约束之前和之后，同一检查操作的执行过程。在没有约束的情况下，要判断“这个工程师是否存在”，就需要读取所有工程师节点的信息并比较它们的电子邮件地址，最终只保留匹配的结果，而其他结果则会被忽略；对于下一行数据，也需要重复这一过程。相应的查询计划显示为NodeByLabelScan。而当设置了唯一性约束后，数据库会自动生成索引，因此可以直接找到对应的节点，而无需遍历所有节点，相应的查询计划显示为NodeUniqueIndexSeek。

当节点数量仅为一千个时，这种检查不会对性能产生明显影响；但当节点数量达到十万个时，导入操作会变得非常缓慢，而且输出结果中也不会说明原因。无论哪种情况，所需的处理成本都是相同的，因此没有必要省略这一步骤。

要想了解自己的查询语句具体是如何执行的，可以在查询语句前加上PROFILE关键字，然后查看最终的执行计划。如果最终显示的是NodeByLabelScan，那就意味着系统中缺少相应的索引，而这正是导致Cypher查询速度缓慢的最常见原因之一。

你完全可以自己验证这一结论，而不必相信我的话：

SHOW INDEXES YIELD name, type, owningConstraint
WHERE owningConstraint IS NOT NULL
RETURN name, type, owningConstraint

name             type     owningConstraint
engineer_email   RANGE    engineer_email
incident_ref     RANGE    incident_ref
service_name     RANGE    service_name
team_name        RANGE    team_name

通过设置这四种约束，系统会自动生成四个范围索引，每个索引都由相应的约束条件所“拥有”。正因为如此，本文中提到的加载脚本才从未单独创建这些索引：这样做是多余的，而且Neo4j也会将其视为冲突而拒绝执行。

Neo4j提供了四种类型的约束条件：

问题在于：只有第一个约束条件在Neo4j社区版中才能正常使用，而这篇文章中提供的Docker镜像正是社区版。另外三个约束条件属于企业版的功能，在Aura环境中可以正常使用。

这意味着同样的脚本在Aura环境下可以成功执行，但在本地的Docker容器中却会失败。这对于初学者来说确实会让人感到困惑。错误信息如下：

Neo.DatabaseError.Schema.ConstraintCreationFailed
无法创建类型为“NODE PROPERTY EXISTENCE”、模式为(:Engineer {name})的约束条件：
该约束条件需要Neo4j企业版才能使用

这不是你的错误，而是版本限制导致的。如果你仔细阅读错误信息，就会发现其中明确提到了这一点。

IS UNIQUE这个约束条件在社区版中是可以使用的，因为这篇文章中提供的Docker镜像正是社区版。此外，它还会生成相应的索引。但是还有另外三种约束条件社区版是不支持的：IS NOT NULL用于检查属性是否存在，IS NODE KEY用于确保某个属性在一个或多个字段中都是唯一的，而某些属性类型约束（比如要求属性必须是STRING类型）也只有在企业版中才能使用。

Aura运行的是企业版，因此同样的脚本在Aura环境中可以成功执行，但在本地电脑上就会失败。这不是你的错误，错误信息中明确提到了这一点：Neo.DatabaseError.Schema.ConstraintCreationFailed，后面还跟着“企业版”这几个字。

这本手册中的所有示例都只使用了IS UNIQUE这个约束条件，因此它们都是在社区版环境中运行的。

CREATE CONSTRAINT engineer_email IF NOT EXISTS
FOR (e:Engineer) REQUIRE e.email IS UNIQUE

请在加载数据之前执行这条命令，而不是之后。

对于那些你经常需要查询但又不唯一的属性，可以创建普通的索引：

CREATE INDEX service_tier IF NOT EXISTS
FOR (s:Service) ON (s.tier)

以下是我们模型中的一些基本约束条件设置：

CREATE CONSTRAINT engineer_email IF NOT EXISTS FOR (e:Engineer) REQUIRE e.email IS UNIQUE;
CREATE CONSTRAINT service_name IF NOT EXISTS FOR (s:Service) REQUIRE s.name IS UNIQUE;
CREATE CONSTRAINT incident_ref IF NOT EXISTS FOR (i:Incident) REQUIRE i.ref IS UNIQUE;
CREATE CONSTRAINT team_name IF NOT EXISTS FOR (t:Team) REQUIRE t.name IS UNIQUE;

在初始化时，用Python一次性执行以下代码：

CONSTRAINTS = [
    "CREATE CONSTRAINT engineer_email IF NOT EXISTS FOR (e:Engineer) REQUIRE e.email IS UNIQUE",
    "CREATE CONSTRAINT service_name IF NOT EXISTS FOR (s:Service) REQUIRE s.name IS UNIQUE",
    "CREATE CONSTRAINT incident_ref IF NOT EXISTS FOR (i:Incident) REQUIRE i.ref IS UNIQUE",
    "CREATE CONSTRAINT team_name IF NOT EXISTS FOR (t:Team) REQUIRE t.name IS UNIQUE",
]

for statement in Constraints:
    driver.execute_query(statement, database_="neo4j")

IF NOT EXISTS 这一语法确保了该代码块在每次系统启动时都能被安全地执行。

查询规划器会如何处理你的查询

Cypher是一种声明性语言。你只需要描述自己想要得到的结果的结构，而无需指定具体的查找方式。这种设计确实非常方便，但这也意味着必须有其他机制来决定具体的执行步骤。

这个负责做出决策的机制就是查询规划器。

当你提交一条查询语句时，Neo4j会首先解析这条查询，然后考虑所有可能的执行方案。对于我们的多跳查询来说，它既可以从事件节点开始查找相关的工程师，也可以从所有的工程师节点开始反向追踪到事件节点。这两种方法最终都会得到相同的结果，只不过前者可能只需要访问少量的节点，而后者则可能需要访问数万个节点。

查询规划器会根据它所掌握的关于你的数据的信息来选择最合适的执行方案。这些信息包括：每种标签对应的节点数量、各种类型的关系数量，以及某个索引属性存在的不同值的数量。根据这些信息，规划器可以估算出每一种执行方案会生成多少条记录，从而选择成本最低的方案。正因为如此，这种查询规划器被称为“基于成本的规划器”，而且每个执行方案的标题中都会显示Planner COST这一字段。

Cypher是一种声明性语言，因此你无需指定具体的查找步骤。不过仍然需要有其他机制来做出决策，而这种决策过程决定了查询执行的速度快慢。查询规划方案其实就是这种决策的书面体现。

对于用户来说，一个重要的结论是：查询规划器其实是在进行猜测。这种猜测是基于真实的数据统计结果进行的，但终究还是猜测而已。如果它的猜测完全错误，那么查询的执行速度就会变得非常慢，而这种问题正是通过查询规划方案来发现的。

EXPLAIN和PROFILE命令的作用

有两个关键字可以帮助你查看查询的执行方案，它们之间的区别也非常重要。

EXPLAIN 命令仅会规划查询方案，而不会实际执行它。你会看到规划器选择的具体操作步骤以及它预估的执行结果所需的记录数。这个命令不会消耗任何资源，因此你可以用它来检查那些可能需要花费很长时间才能完成的查询。

PROFILE 命令则会先规划查询方案，然后再实际执行它。你不仅能得到EXPLAIN提供的信息，还能了解到实际的执行结果：真实的记录数以及每个操作步骤对数据库造成的影响。

下面是同一个查询使用这两种命令得到的结果对比：

EXPLAIN MATCH (e:Engineer)-[:OWNS]->(s:Service {tier:'critical'}) RETURN count(e) AS c

操作步骤                         详细信息                        预估记录数   实际记录数   对数据库的影响次数
ProduceResults                     c                               1              ?            ?
EagerAggregation                    count(e) AS c                   1              ?            ?
Filter                             e:Engineer                   2401              ?            ?
Expand(All)                        (s)<-[anon_0:OWNS]-(e)       2401              ?            ?
Filter                             s.tier = $autostring_0        250              ?            ?
NodeByLabelScan                    s:Service                5000              ?            ?

所有的rows和dbHits数值都显示为“？”，因为实际上没有任何操作被执行。现在来看PROFILE的结果：

操作符                        详细信息                          估计值   行数    数据库访问次数
ProduceResults                c                               1      1        0
EagerAggregation             count(e) AS c                   1      1        0
Filter                        e:Engineer                   2401   7573     7573
Expand(All)                  (s)<-[anon_0:OWNS]-(e)       2401   7573    17871
Filter                        s.tier = $autostring_0        250    786     5000
NodeByLabelScan             s:Service                5000   5000     5001

EXPLAIN用于生成查询计划，而PROFILE则用于实际执行该查询。操作符名称及估计值之所以相同，是因为规划器在这两种情况下得出的结论是一样的。不过，EXPLAIN无法告诉你实际上发生了什么；而在估计结果错误的情况下，这些实际发生的情况才是你所需要的信息。

当你想要了解数据库打算执行哪些操作，或者当运行某个查询会耗费大量资源或导致不良后果时，应该使用EXPLAIN。而当你想要知道查询实际完成了什么操作时，就应该使用PROFILE。

EXPLAIN还有一个非常实用的功能：它可以在不接触任何数据的情况下解析并生成查询计划，因此它是检查某个查询是否有效的最快方法。你可以将代码库中的所有Cypher语句都通过EXPLAIN进行测试，从而在它们被投入生产环境之前发现其中的拼写错误或属性名称变更等问题。

正是配套仓库中的check_cypher.py脚本在做这件事：它从这篇文章中提取出了39个Cypher语句，分别用EXPLAIN进行验证，如果其中任何一个语句无效，程序就会立即停止执行。

阅读查询计划时，请从底部开始

只有这样，查询计划才能真正被人们理解——而这与大多数人的习惯恰恰相反。

查询计划是从底部开始逐行读取的。最底层的操作符是“叶节点”，数据就是从这里进入查询过程的。其上方的每一层操作符都会接收来自下层的数据，对这些数据进行相应的处理，然后将结果传递给上一层。位于顶部的操作符总是ProduceResults，它负责将最终的结果输出到数据库之外。

以上面的查询计划为例，正确的阅读顺序如下：

1. NodeByLabelScan会读取全部5,000个服务对象。这就是“叶节点”：数据就是从这里进入查询流程的。

2. Filter会从中筛选出只有786个关键的服务对象。

3. Expand(All)会根据OWNS关系，从这786个服务对象中反向追踪到对应的工程师信息，从而生成7,573行结果。

4. Filter会再次确认这些对象确实都属于Engineer类型。

5. EagerAggregation会统计这些工程师的数量。

6. ProduceResults最终会返回这个统计结果。

计划是从下往上读取的。最底层的行是数据输入的位置，上面的每一层都会接收这些数据，对它们进行加工处理，然后再将结果传递下去，最终到达ProduceResults阶段。因此，如果从上往下阅读这个计划，起初会觉得它看起来像是一串杂乱无序的信息。

缩进格式用于表示操作符之间的父子关系。一个操作符的子操作符会位于其下一层。大多数操作符只有一个子操作符，而有些操作符（比如连接操作）则有两个子操作符，在这种情况下，右边的子操作符会被放在更靠下的位置，并且会有更多的缩进。

各列的含义

其中有两个概念经常被误解，因此有必要在这里加以说明。

存储引擎的访问次数并不等于生成的行数。这个数值表示存储引擎为执行某项操作而进行的低级访问操作次数：比如读取一个节点、读取某个属性值或读取索引条目等。即使最终只返回了一行数据，也可能需要多次访问存储引擎才能完成这些操作。再来看上面的Expand(All)这条记录：虽然生成了7,573行数据，但存储引擎实际上进行了17,871次访问操作。行数代表最终的结果规模，而访问次数则反映了执行这个操作所消耗的资源。

页面缓存命中/未命中的次数可以用来判断数据是否已经存在于内存中。如果缓存未命中，就意味着存储引擎必须从磁盘上读取数据。在第一次处理从未被访问过的数据时，缓存未命中的情况会比较多；而在第二次处理相同的数据时，缓存命中的情况就会增多。因此，比较两次处理同一数据时的执行时间并不能提供有用的信息。这个列是Enterprise Edition版本才具备的功能，在本文中使用的Community Docker镜像上，这一列的值始终显示为0/0。这并不是一个错误，也不表示你的缓存为空。

整个计划中最有用的信息

请将预计生成的行数与实际生成的行数进行对比。

这种估算值其实是规划者在选择该方案时所依据的假设；而实际的行数才代表真实数据情况。当这两种数值相差不大时，规划者就能根据对数据的准确了解来做出决策；但当它们之间的差异很大时，规划者可能会为一个并不存在的数据集选择相应的方案，而这往往正是导致查询速度变慢的根本原因。

请看上面那个分析报告中列出的数据：

规划器原本认为，如果只过滤掉关键服务，最终剩下的数量应该是5,000中的250个；但在我们的数据中，实际剩余的数量是786个，因为实际上大约有15%的服务属于关键服务，而非规划器默认假设的5%。这种误差会进一步影响后续的决策：由于规划器预计需要250名工程师来处理这些任务，因此它认为需要安排约2,401名工程师，但实际上最终分配了7,573名工程师。

在这个例子中，这种误差带来的后果并不严重。但在处理规模更大的查询时，如果规划器对所需资源的数量估计错误了三倍，那么整个执行策略就很可能会失败，因为它会误以为自己正在将一个小任务与一个大规模的任务结合起来进行处理，而实际上是在同时处理两个大规模的任务。

“预计行数”是指规划器在选择某个执行方案时所预估的结果；而“实际行数”才是最终的实际执行结果。两者之间的偏差往往就是导致查询速度变慢的原因，因为规划器优化的是一个与数据实际情况不符的执行方案。

如果你的所有查询中预测值都一直存在误差，那么这些预测所依据的统计信息很可能已经过时了。

因此，我们应该养成这样一个习惯：运行PROFILE命令后，从报告的底部开始阅读，并仔细核对每一项预测值与实际结果是否一致。你不需要寻找那些巨大的数字，而是要关注规划器在哪个步骤出现了预测错误。

三个值得注意的关键点

这是在Neo4j浏览器中查看PROFILE报告的结果，报告中会显示每一步操作所对应的预计行数和实际行数。这就是NodeUniqueIndexSeek这个操作的解释所参考的实际输出数据。

除了检查预测值之外，方案中还有三处具体的内容值得你特别注意。

当你看到某些具体的操作类型时，它们会告诉你一些重要的信息。NodeByLabelScan这种操作意味着没有使用任何索引；而每个条目都会将问题的症状、原因以及解决方法对应起来展示。

NodeByLabelScan表示数据库会读取所有带有该标签的节点。在起始节点上使用这种操作时，几乎可以肯定是因为缺少索引才导致这种情况的。这是最常见的错误原因之一。