图数据库慢查询怎么排查？执行计划与执行步骤怎么看

一条查询昨天两百毫秒，今天八秒。开发同学的第一反应通常是加索引，加完再跑，还是八秒——不是变慢了，是压根没变。这种情况在关系型数据库里很少见，在图数据库里很常见，因为慢的位置往往不在“找到起点”，而在“展开之后”。起点只有一行，展开出来几千万行，索引帮不上任何忙。

这篇只讲操作：拿到一条慢查询，按什么顺序看，每一眼该看什么，看到什么算找到了。不讲「要建索引」这种结论，因为这句话在图数据库里对一半错一半。

一、先分清是哪一类慢，再决定查什么

慢查询最容易犯的错，是把三种完全不同的问题当成一种来查。

类型	特征	常见原因	第一眼该查
一直慢	上线就慢，与时段无关，换谁都慢	写法问题、扇出爆炸、无界路径	执行计划
突然慢	某天起变慢，此前一直正常	数据变了（出现超点）、数据量涨了、统计信息失真	数据分布
偶发慢	平时正常，高峰期或批量导入时慢	资源竞争、写入挤占读、缓存状态	时段与并发

三者的排查路径几乎没有交集。一直慢要看结构，突然慢要看数据，偶发慢要看资源。混在一起查的典型结局是：加了个索引，重跑一次，觉得「好像快了点」——而从八秒到七点二秒，根本不算优化。

判断是哪一类，只要问两个问题：这条查询以前快过吗？快过的话，是全天稳定地快，还是只在某些时段快？两个问题问完，方向基本就定了。

还有一类要单独排除的「假慢」：查询本身不慢，慢在客户端超时设得太短、或者一次请求被拆成几百次往返。这类问题在执行计划里看不出来，表现却是稳定地慢、且慢得很有规律。先确认服务端耗时和端到端耗时差多少，差得多就不是数据库的事。

二、执行计划要横着读，不是竖着读

多数人读执行计划是竖着读的：从上往下，看每个算子做了什么。这种方式在关系型数据库里管用，在图数据库里几乎读不出问题——因为图数据库的每个算子单独看都不慢，慢的是行数在算子之间被放大。

正确的读法是横着读：把每个算子的估算行数和实际行数排成两列，找第一次出现数量级偏差的那一跳。

举个例子。一条三跳查询，执行计划大概是这个形状：

步骤	算子	估算行数	实际行数
1	按标签与索引定位起点	1,000	1,000
2	展开第一跳邻居	5,000	210,000
3	过滤边类型	4,800	208,000
4	展开第二跳	3,000	4,100,000
5	聚合	200	200

竖着读，五个算子都正常，计划里没有任何一个标红。横着读，问题在第二行就暴露了：估算 5000，实际 21 万，差了四十倍。这一跳的偏差说明第一跳选出的那 1000 个点，平均度数远高于优化器假设的水平。后面的四百万行不是查询写错了，是被这一跳带出来的。

找到偏差的那一跳，比看懂每个算子在干什么重要得多。 这也是为什么执行计划里最有信息量的一列是行数，不是算子名——算子名只告诉你它做了什么，行数告诉你它做砸了什么。

估算为什么会失真？两个常见原因。一是统计信息陈旧，数据涨了一轮但统计没刷新，优化器还按老度数在估；二是优化器默认的度数假设与你的图差得远——多数默认假设来自社交网络那类中等度数的图，而资金网络、设备网络、供应链网络的度数分布是极端长尾的，均值本身没有意义。看到偏差先别怀疑优化器坏了，先怀疑它不知道你的图长什么样。图数据库的性能优势本来就建立在多跳关系上（图数据库性能优势有哪些讲过这层机制），代价也在这里：跳数越多，估算误差被放大的倍数越大。

三、图数据库的三个嫌疑点：扇出、超点、无界路径

跑过几十条慢查询之后会发现，九成的图数据库慢查询落在这三类上。

嫌疑点	症状	执行计划里的样子	处置方向
扇出爆炸	多跳之后行数成指数增长	某一跳后实际行数比估算高几个数量级	先聚合再展开，收窄中间结果
超点	特定几个 ID 慢，换 ID 就快	单点展开后行数异常高，且每次都固定在同一个点	拆点、按边类型分流、加中间层
无界路径	变长路径查询偶发极慢，时间不可预测	展开次数不受控，行数量级跳变	加上界，或改成定长展开

扇出这件事算一遍就明白。第一跳选出 1000 个点，平均度数 30，第二跳就是 3 万行；如果这 1000 个点里混进 10 个度数为 5 万的超点，第二跳直接变成 53 万行。平均度数 30 和真实分布之间，差的不是精度，是数量级。这也解释了为什么「平均度数不高」的图照样会炸——平均数从来不管最坏的那几个点。

超点这一条值得多说两句。 一个点挂着几百万条边，任何经过它的遍历都会炸，而它自己在建图时毫不起眼——可能是一个公共账户、一个默认分类、一个「其他」标签、一个测试账号。这类点的问题在于：它不是数据错误，是数据特性，清理不掉，只能在建模和查询两头处理。

识别超点有个快办法：把同一条查询里的起点 ID 换成另一个，如果速度差十倍以上，基本可以断定起点落在超点上。这个操作三十秒能做完，比翻监控图表快。

四、五个动作，按成本从低到高

排查顺序应该是成本从低到高，而不是从最熟悉的开始。

顺序	动作	成本	能得到什么
1	看执行计划	分钟级	定位到哪一跳开始放大
2	把查询拆成前缀逐段跑	十分钟	确认第几跳开始超时，排除聚合与排序的影响
3	变长改定长，验扇出假设	十分钟	判断是路径无界还是某跳度数过高
4	换起点，从选择度高的条件出发	半小时	把入口从宽集合换到窄集合
5	加索引、改建模	天级	治结构性问题

第五步放在最后，原因很直接：关系型数据库里索引是万能药，图数据库里索引只治第一跳。 索引解决的是“从全图里找到满足条件的那几个点”，它不解决“这几个点展开出来有多少”。慢在第二第三跳时，加索引是纯粹的无效功，还会让人误以为已经优化过一轮。

拆前缀的具体做法：把一条三跳查询拆成 A-[*1]->x、A-[*2]->y、A-[*3]->B 三条分别跑，看哪一条开始超时。后两条都慢往最后一跳找扇出，第一条就慢则问题在起点。这个动作土得不像技术活，但它把「三跳查询慢」变成「第二跳开始慢」，问题范围一下缩小十倍。更细的拆法见图数据库实战指南与技巧。

很多人跳过这两步直接改写法，改完发现没用，又改回去，来回几轮，时间全耗在这里。

五、验证优化有没有真效：三个必须固定的条件

改完之后跑一遍变快了，不代表优化成立。三个条件不固定，测出来的数字没有意义。

第一，同一份数据。 优化期间数据量涨了，快了也可能是假的；反过来，删了批历史数据变快，那是数据的问题不是优化的问题。

第二，同一并发。 单条查询从八秒降到两百毫秒，和五十并发下从八秒降到两百毫秒，是两件事。图数据库的并发表现和单条性能不是线性关系，深跳查询占内存多，并发一上来，单条的最优解可能反而是整体最差的那个。

第三，缓存状态一致。 第一次跑和第二次跑差一倍是常事，因为热数据和冷数据的访问代价差很远。要比较，就得保证两次测量都从同样的缓存状态出发，或者各跑三次取稳定值。

指标口径也要改一次：看 P99，不看均值。 均值会被大量轻查询稀释掉，而线上真正出问题的那一刻，是某条深跳查询在高峰期把连接池占满——那条查询在均值里几乎没有权重。

六、两个误区与一份可以直接用的检查清单

误区一：先加索引。 前面说过，索引只治第一跳。更麻烦的是它给了人一种“我做过优化了”的错觉，把真正该看的执行计划挡在后面。

误区二：把慢查询当成查询问题。 相当一部分慢查询，根子在建模，调优阶段补不回来。最典型的是稠密关系：一对实体之间可能产生成千上万条关系（一天几百笔交易、一天几百次通话），把它建成边，那个实体就成了超点；建成点，遍历就多一跳、多一层过滤。这个取舍必须在建模阶段定，等跑慢了再改，等于重建图。

调优能做的只有“让图在现有结构下跑得更快”，做不了“让结构变合理”。这句话值钱的地方在于：它能帮你判断什么时候该停手，去谈建模改造，而不是继续在查询语句上抠。

下面这份清单可以照着走一遍。

#	检查项	怎么看	什么算异常
1	查询属于哪一类慢	以前快过吗，全天稳定吗	说不清属于哪类，先别动手
2	执行计划估算与实际行数	逐跳对比两列	某一跳差一个数量级以上
3	起点选择度	起点集合有多大	起点是全集或大类标签
4	中间结果规模	每跳后行数	出现万级以上且后续还要展开
5	是否经过超点	换起点 ID 重跑	速度差十倍以上
6	变长路径有无上界	路径写法里的跳数范围	无上界或上界大于五
7	过滤条件能否前移	过滤在展开前后	先展开再过滤
8	验证条件是否固定	数据、并发、缓存	只跑过一次就下结论

慢查询排查这件事，说到底是一句话：先确定它慢在哪一跳，再决定改什么。 跳数定位不了，改什么都是碰运气；跳数定位了，改法往往只有一两种，选哪个都不难。

相关阅读

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 自主可控，原生支持 ISO-GQL 国际标准，采用存算分离与 Shared-Nothing 架构，面向千亿点万亿边规模的关系数据存储与查询，多跳查询延迟在毫秒至百毫秒级。产品内置图算法库，并提供可视化图数据分析能力，支持在超大规模关系网络上做遍历与计算。

Q2：排查慢查询一定要先上监控平台吗？单条排查需要准备什么？

A：不需要。单条慢查询的排查，执行计划和一次可复现的查询就够了，前提是能拿到估算行数与实际行数这两列。监控平台解决的是另一个问题——发现哪些查询在变慢、慢的趋势如何、影响面多大。两件事的顺序应该是先手工定位几条典型慢查询，弄清慢的模式，再决定要不要上平台；反过来先上平台，通常会把注意力引到一堆不重要的指标上。

Q3：悦数图数据库在查询调试与可视化运维上有哪些工具？

A：开发侧有悦数 Studio，支持图数据浏览、查询调试、路径可视化与图谱探索，慢查询可以在调试界面里直接看遍历过程，路径结果可视化后也更容易判断扇出是从哪一步开始的。运维侧有面向运维的 Dashboard，覆盖集群监控与运维操作；产品提供完整审计日志，记录不可篡改，便于事后追溯慢查询与异常操作。计算侧另有悦数图分析，通过 GQL 存储过程封装算法与业务逻辑，与传统图处理框架 Spark GraphX 相比处理速度可达其 6 至 10 倍，资源占用降低 80%，适合把复杂的多跳计算从在线查询里剥离出去。