当前位置：首页 > news >正文

了解 PostgreSQL 的扩展查询协议

news 2026/2/7 14:37:27

1.介绍

本篇博客用于解释扩展协议的工作原理以及它与简单查询的区别。

2.简单查询

在PostgreSQL中，客户端连接能够发起两种类型的查询：简单查询和扩展协议查询。

简单查询顾名思义。

当启动 psql 客户端连接到pg服务器时，几乎所有发送的sql命令会被视为简单查询。

包括使用 begin 和 commit 包起来的显式事务；使用分号分割的多语句查询；执行或定义函数等等。

简单查询自动遵循标准查询处理流程，其中包括以下阶段：

Parser
Analyzer
Rewriter
Planner
Executor

这些具体含义这里不再赘述。网上的资料很多。

客户端和服务器之间的通信也非常简单。

case 1, insert

客户端将查询发送到服务器进行处理，服务器响应一个 CommandComplete 消息（比如 INSERT 0 1，接一个ReadyForQuery(IDLE)消息），表示现在服务器已经完成了查询，目前是闲置状态，客户端可以发送另一个查询，新的查询遵循同样的逻辑。

case 2, select

在 SELECT 查询的情况下，服务器将先发送结果 row 的行结构描述，然后发送满足查询的实际行数据，直到没有更多行可返回为止。

最后，服务器发送一个 ReadyForQuery(IDLE) 消息，表明服务器已经完成查询，现在处于空闲状态。

3.扩展协议查询

扩展查询是客户端完成查询的另一种方式，它将标准查询处理分解为不同的步骤。客户端需要确保正确执行这些步骤。

客户端能够发送以下协议消息类型来控制：

‘P’ message (Parse)

采用通用查询字符串，其中数据值替换为 $1、$2 等占位符，稍后可以在 'B’ 步骤中替换为实际值。
该字符串会经历以下阶段：Parser -> Analyzer -> Rewriter
在 Parse 阶段成功后，会创建一个 prepared statement ，类别于sql中的PREPARE
prepared statement 可以是命名或者 未命名 的（下面详细介绍）
prepared statement 只是输入查询的一种表示，还不能执行。

‘B’ message (Bind)

'B' 阶段将会把 ‘P’ 阶段创建的prepared statement，替换掉 $1、$2 等占位符，改为用户提供的值。
将值替换掉后，将会获得一个完整的查询语句，之后会由Planner生成执行计划。
构建执行计划成功后，会生成一个portal。
portal也可以是命名或者未命名的。
portal基本上是一个对象，表示如何执行特定查询。

‘E’ message (Execute)

‘E’ 阶段会真正执行 ‘B’ 阶段生成的portal对象。
生成结果行（如果有），然后发送给客户端。

‘S’ message (Sync)

在一条语句最后，客户端必须向服务器发送 S 消息以指示扩展查询的结束。
此消息会让服务器结束当前事务，并将 ReadyForQuery(IDLE) 消息发送回客户端。

将一个简单的查询分成多个步骤的目的是什么？

使用扩展查询的一大好处是它可以节省大量不必要的相同查询结构的解析。

相反，我们可以只解析一次公共结构，然后多次绑定和执行不同的值。

4. 命名和未命名的prepared statement、portal

这一节用来讨论命名和未命名的prepared statement、portal有什么意义。

一般情况下，PostgreSQL 服务器只能保留一个未命名的prepared statement或者portal。

新的未命名的prepared statement或者portal将替换现有的。

而使用命名的prepared statement或者portal，服务端将会进行存储，客户端可随时调用或者发送Close message.进行销毁。

因此，客户端可以在一个事务中创建多个prepared statement，每个都有不同的名字，然后通过给它们不同的portal名称同时为它们绑定值。最终，客户端选择要执行的portal。

More importantly, named prepared statement’s life time lasts for the entire TCP session unless explicitly destroyed; named portal lasts only until the end of transaction or when it is executed or explicitly destroyed.

以libpq为例，当使用扩展查询时，需要客户端应用提供prepared statement name来构造P(Parse)消息，而不需要客户端应用提供portal name来构造B(Bind)消息。

这意味着使用 libpq，我们可以使用不同的prepared statement名；但是对于 B 消息，它强制使用unnamed portal，所以我们总是有一个portal执行，这避免了在客户端管理多个portal名称的情况。

翻译自：

A Look Inside PostgreSQL's Extended Query Protocol - Highgo Software Inc.