社交推荐为什么慢？三度人脉查询的性能排查与图数据库实战

大家好，我是数据库小学妹 👋我踩过的坑，你别再踩。

上个月帮朋友排查社交推荐系统。核心需求很简单，找出"我关注的人关注的人"做二度人脉推荐，再加"我关注的人关注的人关注的人"做三度人脉。MySQL里用一张自关联关注表实现。一度人脉走索引毫秒级，二度人脉两次JOIN到百万用户后8到15秒，三度人脉再加一次JOIN直接飙到45到120秒。

优化手段试了一圈，关注表加了复合索引，EXPLAIN看了执行计划，FORCE INDEX强制走索引也没用。因为中间结果集太大了，索引只能加速单次查找，解决不了中间数据爆炸。朋友后来换了Neo4j，同样的三度人脉查询降到0.05秒。

这个差距让我很不服气。我花了两周时间拆了Neo4j的底层机制，从存储文件格式到查询执行计划，一点点对照MySQL的执行逻辑。今天把排查过程和技术细节整理出来，帮你少走弯路少踩坑。

一、MySQL 做图查询为什么慢

社交关注关系通常用一张自关联表建模，user_id和follow_id做联合主键，follow_id建普通索引。查二度人脉时需要把这张表和自身做JOIN，再用NOT IN子查询排除已关注的人。一度人脉查起来很快，走主键索引直接定位user_id=123的记录。二度人脉拿一度结果集去第二张表里找，假设平均每人关注50人，50乘以50中间结果集就是2500行。三度人脉再加一次JOIN，2500乘以50膨胀到12.5万行。

问题不在单次JOIN的速度，而在于中间结果集每多一跳就指数级膨胀。MySQL的JOIN策略是先做笛卡尔积展开再过滤去重，中间数据量大了就会落到磁盘临时表。这就是EXPLAIN显示type是ALL的原因。FORCE INDEX强制走索引后情况没好转，因为索引优化的是"找一行"的速度，但JOIN要做的是"找所有匹配行"。当匹配行数太多时，索引本身就不够用了。

二、图数据库为什么快：从概念到存储

2.1 索引无关性

图数据库快的核心原因是索引无关性。关系型数据库做JOIN时，每次都要走B+树索引查找，时间复杂度O(log N)。三度人脉是两次JOIN，就是两次O(log N)查找，中间结果集大的时候总时间等于行数乘以log N。图数据库的做法不同，每个节点在磁盘上直接记录了它所有相邻节点的物理位置指针，遍历时不需要走索引，顺着指针走就行。在缓存命中的理想情况下，每步接近O(1)，但实际还要受磁盘IO和缓存命中率影响。

关键区别在于MySQL先展开再过滤，图数据库边遍历边过滤。

2.2 Neo4j 底层存储结构

我之前一直以为图数据库就是"把关系当一等公民"。直到我拆开Neo4j的存储文件，才发现事情没那么简单。

Neo4j的核心是节点和关系两类记录。早期版本（3.x）里节点记录9字节、关系记录33字节。到4.x和5.x，节点记录涨到15字节，关系记录变为34字节。增量来自新增的版本标识和扩展标记字段。

节点存储里记录了该节点第一条关系和最后一条关系的文件偏移量。关系存储里记录了源节点、目标节点、关系类型，以及同类型的前一条和后一条关系的双向链表指针。从123号用户出发查一度人脉，直接读节点记录的第一条关系指针，然后沿双向链表遍历直到最后一条关系，每条关系又指向目标节点。整个过程就是磁盘顺序读加链表遍历。

不需要B+树，不需要哈希表，不需要JOIN。文件偏移量就是天然索引。这也是为什么我说"索引无关性"——节点本身就自带了指向邻居的物理地址，不需要额外建索引来关联。

2.3 Cypher 查询的执行计划

写Cypher查询和写SQL一样，也需要看执行计划。用EXPLAIN看三度人脉的Cypher查询：

EXPLAIN MATCH (me:User {user_id: 123})-[:FOLLOWS*2]->(candidate:User) WHERE NOT (me)-[:FOLLOWS]->(candidate) RETURN DISTINCT candidate.user_id;

执行计划大概是这样的：

+------------------+------------------+-------------------+ | Operator | Estimated Rows | Details | +------------------+------------------+-------------------+ | +ProduceResults | | candidate.user_id | | +Distinct | 2,500 | candidate | | +Filter | 2,550 | NOT (me)-[:FOLLOWS]->(candidate) | | +VarLengthExpand | 2,550 | (me)-[:FOLLOWS*2]->(candidate) | | +NodeIndexSeek | 1 | User.user_id = 123 | +------------------+------------------+-------------------+

先通过节点索引定位起点1行，然后VarLengthExpand沿着FOLLOWS关系走两步，Filter排除已关注的人，Distinct去重。这里的关键是VarLengthExpand，它不是展开笛卡尔积，而是在图上做BFS遍历。Neo4j 5里VarLengthExpand有All、Into、Pruning多种模式，查询规划器会根据查询模式自动选择。Pruning模式支持剪枝优化，能减少无效路径的遍历。每层只遍历当前节点的直接邻居，中间结果不膨胀。

2.4 性能对比

我的测试环境是阿里云ecs.g6.xlarge，4核16G，ESSD云盘。Neo4j 5.15社区版，Python faker脚本生成100万用户，每人随机关注30到80人，平均50人，数据总量约5000万条关系。MySQL用InnoDB，innodb_buffer_pool_size设8G，Neo4j用默认配置。

四度人脉时差距最大。MySQL中间结果集膨胀到数百万行，已经开始用磁盘临时表。Neo4j依然是在内存里跟着指针走。

三、图数据库的典型应用场景

社交推荐是最直接的场景。但不是唯一的。

知识图谱是另一个重要方向。A是B的创始人，B投资了C，C的产品用了D技术。查询"某公司使用的技术栈的创始人还创办了哪些公司"，关系型数据库要五到七张表JOIN。图数据库就是沿几段边走。最近GraphRAG在LLM领域很火，核心就是用图数据库构建知识图谱，让大模型沿着图谱推理，比纯文本检索准确率高不少。

除了Neo4j这类专用图数据库，还有一条多模融合的路子。KingbaseES V9把图模型、关系模型、向量模型放在同一个引擎里。做Graph-RAG时，图查询和向量检索在一条SQL里完成，不用跨库对接。信创场景里，这种多模一体架构的优势是部署一套系统就能覆盖关系数据加图查询的混合需求。

风控也是典型场景。判断一个用户和已知欺诈账户有没有关系，共用设备、共用IP、共用收货地址。从目标用户出发，沿着设备、IP、地址关系边查找，看能否到达已知欺诈节点。关系型数据库要维护多张关系表做关联，图数据库就是几个MATCH模式组合。在数据治理场景里，图模型还能用来追踪数据血缘，理清数据来源、流转和变更的关系链。

还有推荐系统的协同过滤。买过A的用户也买了B和C。图数据库里是两步路径查询。从用户节点出发沿购买关系找到已购商品，再从商品节点找到其他购买过它们的用户。最后统计他们购买的其他商品。

四、我踩过的坑

4.1 稠密节点问题

这是我一开始没想到的。社交场景里，明星或大V的粉丝数可能上百万。这种节点叫稠密节点，在Neo4j里遍历一个百万粉丝的节点需要读100万条关系记录。即使每条关系只有34字节，也要扫描30多MB数据。我测试过一个模拟场景，一个节点有200万条关系，从它出发做二度查询，耗时从50毫秒涨到15秒。

解决办法有几个方向。把稠密关系拆分成子图，按时间或地区分片。或者把大V的关注关系单独存到Redis里，图数据库只存普通用户的关系。也可以在Cypher查询里加SKIP和LIMIT控制遍历深度。

4.2 别把全量业务数据搬进图数据库

一个常见错误是把整个业务系统全搬到图数据库，用户信息、商品库存、订单记录全建成节点。这样做性能不会提升，因为图数据库擅长的是多跳查询，不是单表增删改。范围查询和聚合统计在图数据库上表现很差。查过去30天销售总额，关系型数据库有成熟的索引和聚合优化，图数据库需要遍历大量节点再汇总，开销很大。正确的做法是图数据库只存关系数据，业务数据留在关系型数据库，通过ID做关联。

4.3 分布式图数据库的性能陷阱

Neo4j单机版性能强劲但容量有限，超过一定规模需要集群版或者换JanusGraph加HBase。但分布式图数据库的图遍历性能远不如单机版，跨节点的边遍历需要网络通信。我的测试数据从单机Neo4j迁到JanusGraph后，三度人脉查询从0.05秒涨到2秒，差距来自跨机器的RPC调用延迟。

我的建议是单机Neo4j能满足就用单机。实在需要分布式再考虑JanusGraph，但要做好性能下降的心理准备。迁到分布式之前一定要做充分的性能压测，不要只看功能能不能用，要看延迟能不能接受。

4.4 图数据库建模不是表翻译

新手常犯的错是把关系型表直接翻译成图节点，一张表变成一个节点类型，外键变成关系边。这样做能用但浪费优势。图数据库建模应该从查询出发，先明确最常执行的查询模式，再决定节点和边的粒度。比如社交场景中关注可以建模为关系边，但点赞应该建模为边还是单独节点？只需要判断用户A是否点赞过内容B，用边就够了。如果需要查询谁在什么时候点了什么赞，就需要单独节点来承载时间属性。

五、两种图能力技术路线的选择

到这里你可能会问：我到底该选哪条路。市面上主要有两种图能力方案。

5.1 专用图数据库路线

以Neo4j为代表。优势是图遍历性能强劲，社区生态成熟，Cypher语法学习成本低。但代价也很明显。

Neo4j社区版只支持最多4个CPU核心，不支持集群，只能用冷备份，Cypher运行时是Slotted版而非企业版的Pipelined或Parallel。生产需要高可用的话得买企业版。单机容量上限是320亿节点和320亿关系，超过这个数就得考虑分布式。

专用图数据库还有一个隐性问题：它只负责图数据。你的用户信息、订单记录、权限配置还得留在关系型数据库里。两套系统意味着两套部署、两套监控、数据同步要额外做。

5.2 多模融合路线

KingbaseES V9的思路不同。把关系模型、图模型、文档模型、向量模型放在同一个数据库引擎里。图查询和关系查询用同一套SQL接口完成，不需要额外部署图数据库系统。

这对信创场景特别重要。政务、电力、金融这些领域本来就在用国产数据库，图查询能力如果作为同一个数据库的内置功能，部署成本、运维复杂度、跨库数据同步的问题都省掉了。

而且多模融合还解决了一个实际痛点：Graph-RAG场景需要同时做图查询和向量检索，在专用方案里要对接两套系统，多模架构里一条SQL就能完成。

5.3 怎么选

我的建议很直接。如果你的场景是纯图查询，数据量大到需要专用优化，选Neo4j这类专用图数据库没错。但如果你已经在用关系型数据库，图查询只是系统里的一部分需求，多模融合架构可能更务实。少一套系统，少一个运维点，少一次跨库同步的风险。

图数据库不是什么神秘的东西。它解决的是关系型数据库在多跳查询上的天然短板。选哪条路取决于你的系统现状和团队能力。

避坑清单

如果你的图查询需求只是偶尔跑一下三度人脉，MySQL加合理索引也能扛。别被"图数据库"三个字裹挟着做过度设计。能一条SQL搞定的事，不需要额外部署一套系统。这个判断直接影响后续的架构复杂度和运维成本，一开始就想清楚。

信创场景里优先考虑多模融合架构。政务、电力、金融这些领域本来就在用国产数据库，图查询作为KingbaseES V9的内置能力集成在同一个引擎里，部署一套系统就能覆盖关系数据加图查询的混合需求。少一套系统就少一个运维点，少一次跨库同步的风险。

图数据库的备份策略和关系型数据库差别很大。Neo4j社区版只有冷备份，生产环境要做在线备份得买企业版。规划架构时要把备份方案一起考虑进去，别等上线了才发现社区版的备份能力不够用。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见 👋