Graph Query Language(GQL，图形查询语言)是由同时维护SQL标准的国际工作组开发和维护的一种新语言。
GQL很大程度上借鉴了现有的语言，主要的灵感来自Cypher(现在实现版本有10多个，包括6个商业产品)、Oracle的PGQL和SQL本身。GQL项目是自SQL之后的第一个ISO/IEC国际标准数据库语言项目。
今年6月，隶属ISO/IEC联合技术委员会1(负责定制IT标准)的全球诸多国家性标准机构开始就GQL项目提案进行表决，有七个国家派出专家参与这项为期四年的项目。在本周投票结束，提案获得通过。
共有十个国家投出了赞成票，其中包括中国、韩国、瑞典、美国、德国、英国、荷兰、丹麦、哈萨克斯坦、加拿大和芬兰。另外有五个国家选择弃权，其理由是缺乏对该提案作出判断或发表评论的专门知识。
只有日本投了反对票，它列举了两个理由：
现有的语言已经能实现这类需求
具体来说，SQL/Property Graph Query扩展以及SQL标准的其余部分可以满足需求
为什么我们需要一种特定于图形的查询语言？
许多供应商、研究人员和用户一致认为，可以使用非关系型“图形原生”存储和运行时模型来开发图形数据库。例如Neo4j的行业领先的图形数据库平台和新的Redis Labs图形产品。
但是，他们也需要一种类似 Cypher 的语言来支持数据的插入和维护，而不仅仅是数据查询。对于以图行为中心的语言来说，SQL不太可能是一个合适的模型，所需的语言是能够将图形作为查询输入，然后输出一个图，就像SQL可以读取表，并生成实为新表的结果集。
GQL和SQL如何协同工作？
许多支持GQL 提案的公司和国家标准机构并不认为GQL和SQL是竞争对手，而是通过共享的基础和互操作来相互补充。(其中指的是核心数据类型和表达式的形成方式，以及共享的概念，如目录中持有的模式对象，以及与用户/角色相关的会话)。
SQL/PgQ查询实际上是一个围绕着一段“proto-gql”的SQL子查询。下面有一个示例查询，在今年SIGMOD 大会接近尾声时，Oracle 的Oskarvanrest为今年7月在阿姆斯特丹举行的链接数据库基准理事会(Link Database Benchmark Council)会议提出的。
以关键字MATCH开头的红色部分是模式匹配查询的一个片段，该查询非常类似用Cypher或PGQL编写的查询。你可能会注意到，它用于引入标签(如在Creator IS Person 中)，以及用于引入主机参数或变量。但是，你也可以在标签表达式中使用冒号(如果SQL引擎的解析器是智能地)，那么与先前存在的“输入”属性图查询语言的相似性就会更加明显。
PgQ查询的其他部分(黑色和绿色)将这个Proto-GQL连接到一个SQL SELECT语句中。表格结果通过Columns子句流到常规SQL查询中。它们只关注与图形查询交互的SQL引擎，GQL本身不会涉及到这种SQL“外部函数接口”。
SQL 生成表，GQL 生成图
SQL是一种在一个关键方面与 cypher 语言大不相同。Cypher 让用户在不知道将返回哪些类型的数据的情况下探索其数据图的结构。它可以让你进行真正的图形查询，其中值得关注不仅仅是值，还包括数据子集的形状，定义与匹配图形模式的元素值方面。换句话说，图查询针对在一个或多个输入图上计算的子图或投射图。
GQL将建立在 openCypher Morpheus 的基础上(它将Cypher引入到Apache Spark)，并结合来自LDBC的G-CORE的灵感，为用户提供了一种组合图查询语言，支持所有那些功能，这将使GQL在概念上等同于SQL。
更普遍地说，GQL是一种比SQL更现代的语言，它具有更结构化的类型系统。
GQL项目的工作将于本月晚些时候在坦桑尼亚阿鲁沙召开的SQL/GQL标准委员会ISO/IEC JTC 1 SC 32/WG3的下一次会议上全面开始。
目前还无法确定GQL的第一个可实现版本，但很有可能在2020年下半年之前制定某个相当完整的草案。
