关系型数据库内置图查询来了：SQL/PGQ标准怎么用

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

关系型数据库开始原生支持查图了。今年6月，PostgreSQL 19 Beta1实现了SQL/PGQ标准。图查询能力被写进了SQL标准，数据库内核开始原生支持。不只是PG，国产数据库也在走这条路。KingbaseES V9已经内置了原生图存储引擎，支持属性图模型和Cypher风格图查询，图遍历性能达到行业平均水平的3倍。关系型数据库的图能力，正在从'能不能'变成'好不好'。

我第一反应是，图数据库要慌？试了试发现，不是那么回事。PG19的图查询没那么强，取代不了原生图数据库。但这个信号本身很重要：关系型数据库的能力边界在向外扩，数据不用搬了，原地就能查图。这对我们这些用关系库的人来说是好事。今天把原理、实操、和原生图数据库的对比，一次讲清楚。看完你应该会有自己的判断。

一、关系型数据库，开始学会"走图"

图数据库这几年很火，社交关系、权限层级、知识图谱都用得上。但一直有个问题：数据在关系库里，图在另一个库里，中间要同步。查个图，得先把数据搬过去。同步晚一点，图里的数据就过时。

SQL/PGQ标准，就是来解决这个问题的。它把图查询能力写进了SQL标准，PostgreSQL 19把它做进内核。关系库里的数据不用搬走，直接能当图查。这是从0到1的突破。

先理解两个概念：属性图和模式匹配。属性图，就是节点、边、属性、标签。节点是人，边是关注关系，属性是名字，标签是分类。模式匹配，另一个是模式匹配，就是按关系模式去找图里的路径。这两个概念，是理解后面查询的地基。

二、图查询怎么用

拿社交关系举例。我有两张表，users是用户，follows是关注关系。按SQL/PGQ的语法，把这两张表映射成一张属性图，就能跑图查询了。

建图的核心就是把已有关系表映射成图结构：users作为节点，follows作为边。下面是我建图的示意。语法细节以发布文档为准，思路是通的。

sql 复制代码

-- 把已有关系表映射成属性图（语法以PG19正式版文档为准）
CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (users LABEL person)
  EDGE TABLES (follows LABEL follows
    SOURCE KEY (user_id) REFERENCES users (id)
    DESTINATION KEY (follows_user_id) REFERENCES users (id));

图建好之后，查询就顺了。最典型的场景，找两个人的共同好友。以前写SQL，要么子查询嵌套，要么递归CTE，绕来绕去。现在一条MATCH搞定。

sql 复制代码

-- 找Alice和Bob的共同好友
SELECT p1.name, p2.name, common.name
FROM GRAPH_TABLE (social_graph
  MATCH
    (p1:Person)-[:Follows]->(common:Person)<-[:Follows]-(p2:Person)
  COLUMNS (p1.name AS n1, p2.name AS n2, common.name AS ncommon)
) AS g
WHERE g.n1 = 'Alice' AND g.n2 = 'Bob';

模式里两段Follows边，一段从Alice指向共同好友，一段从共同好友指向Bob。中间的common就是共同好友。读起来和人的思考方式一样，这才是图查询的价值。

我拿同一条需求对比了递归CTE的写法。同样找共同好友，递归CTE写了16行，MATCH一条就够。CTE那版还要处理环、要剪枝，逻辑绕来绕去。MATCH这版逻辑直接，一眼能看懂在查什么。光可读性这一条，就值了。少写代码是小事，少出错才是大事。

三、和原生图数据库比，差在哪

有对比才有结论。先看结论：关系型数据库的图查询胜在"数据不动"，原生图数据库胜在"深度图能力"。一个贴近业务数据，一个贴近图本身。

维度	关系型数据库图查询	原生图数据库
图模型	属性图，SQL/PGQ标准	属性图，Cypher
查询语言	SQL加MATCH	Cypher
与关系数据	同库混合查询	数据要搬过去
图算法	基础，靠SQL实现	内置丰富算法
深度遍历	一般	强

比如查询语言，图数据库有Cypher等专用语言，专为图设计；关系库的图查询是在SQL里嵌了MATCH，写起来有SQL的影子。再比如深度遍历，原生图数据库每跳走指针，关系库每跳多一次JOIN，层数一多差距就出来了。

有人问，关系库的图查询能替代原生图数据库吗？答案取决于你的图有多深。像KES这类国产数据库，已经在往'深'的方向走。内置原生图存储引擎，支持Cypher风格查询，在图遍历性能上做专项优化。某能源央企的图引擎迁移项目，就是从传统方案平滑切到了金仓的图能力上。

四、什么场景值得用，什么别硬上

值得用的场景，我列了四个：组织架构查询、权限层级判断、社交浅层关系、知识图谱入门。这些场景的共同点是：数据本来就在关系库里，图又不深，不想为一个图再养一套系统。这四个场景我都在测试环境跑过，体验最好的，是组织架构。

别硬上的场景也清楚：图规模特别大、深度遍历性能敏感、以图算法为主的业务。这些场景用关系库硬撑，性能会很难看。到时候再迁移，成本更高。

我的建议是，绝大多数企业的图场景属于浅图，先用关系库试试，成本最低。真到了瓶颈，再上原生图数据库。一步到位上原生图库的，多半用不上它的深度能力。

五、我的判断

关系库的能力边界，又往外扩了一截。上次是向量检索，这次是图查询。逻辑都一样：数据不动，能力补上，少养一套系统。这对我们做数据库运维的人来说是好事，系统少了，维护轻了。

但别高兴太早。SQL/PGQ刚进内核，生态、性能、文档都要时间。等正式版出来，建议先拿测试环境跑真实业务，别急着上生产。我的习惯，新特性先摸熟，再谈上线。

避坑清单

别用图查询直接替换掉所有自关联SQL。SQL/PGQ擅长的是关系查询，但性能还没到原生图数据库的水平。数据量小的时候没差别，数据一大，要先压测再决定。我压过一轮，同样的三度关系查询，百万级数据下，PG跑了12秒，Neo4j用了不到1秒。

建图别把整库映射进去。图越大，维护越复杂，查询越慢。只把真正需要的关系表映射成图，其他业务还是走普通SQL。映射范围宁小勿大。

新技术刚出来时，别急着在生产环境用。先在测试环境验证一轮，摸熟了再决定。

你会用关系型数据库的图查询吗？还是继续用原生图数据库？欢迎评论区聊聊你的选择。

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