解析Cloud SQL日志中PostgreSQL实例的duration数值差异问题

Cloud SQL日志中的duration字段确实是由Cloud SQL服务计算的，而非PostgreSQL本身统计的执行时间，两者的时间统计范围完全不同，这是差异的核心原因。

PostgreSQL的EXPLAIN ANALYZE仅统计数据库引擎内部处理查询的时间：从解析查询、生成执行计划、扫描数据到生成结果的全过程，完全不涉及数据库外部的任何开销。

而Cloud SQL的duration统计的是从接收客户端请求的第一个字节开始，到发送完响应的最后一个字节结束的全链路总耗时，额外消耗时间的因素包括：

• 网络传输开销：客户端与Cloud SQL实例之间的网络往返时间，包括请求数据包的传输、响应数据的回传。即使是SELECT 1这类极小请求，也会存在基础的网络路由、GCP内部负载均衡转发的耗时；如果查询返回较大结果集，数据传输的耗时会占比更高。
• 中间代理层处理：Cloud SQL在客户端与PostgreSQL实例之间存在一层代理服务，负责处理SSL/TLS握手、IAM身份认证、连接池管理、请求路由、日志采集前置处理等操作，这些步骤都会增加额外耗时。
• 连接相关开销：如果执行查询时使用了新建立的连接，还会包含TCP三次握手、PostgreSQL会话初始化（如设置时区、search_path）、用户身份验证的时间；即使是复用已有连接，代理层也可能会做连接健康检查等操作，带来少量开销。你的SELECT 1案例中150ms的耗时，很大概率就包含了这类连接相关的基础开销，而EXPLAIN ANALYZE是在已建立的会话内执行，不会统计这部分时间。

如果需要更精准地排查客户端到数据库引擎的实际耗时，可以使用psql的\timing命令，它会统计从客户端发送请求到收到响应的往返时间，这个数值会介于EXPLAIN ANALYZE的时间和Cloud SQL日志的duration之间，能帮你区分网络与数据库内部的耗时占比。

内容的提问来源于stack exchange，提问作者Vishal Sharma