PostgreSQL 10.4普通查询与EXPLAIN ANALYZE耗时差异问题咨询

普通查询返回的506ms #

这是客户端触发查询到完全拿到结果的端到端总耗时，覆盖了全链路所有环节的开销：

• 客户端和Postgres服务端的连接创建开销（如果使用短连接每次查询新建会话，这个开销占比会非常高）
• 查询语句从客户端传输到服务端的网络开销
• Postgres的查询解析、语义校验、执行计划生成开销
• 内核执行查询的时间
• 结果集序列化、从服务端回传到客户端的网络开销
• 客户端接收、渲染展示结果的开销

EXPLAIN ANALYZE返回的0.008秒 #

这是Postgres内核执行器实际运行查询的纯执行耗时，仅统计数据读取、计算的时间，不含上述的连接、网络、计划生成、结果回传等外围开销。如果你看的是EXPLAIN ANALYZE输出里的Execution Time字段，对应的就是这个值，旁边的Planning Time是生成执行计划的时间，两者加起来通常也远低于506ms。

• 0.008秒的执行耗时完全符合预期：7行数据的小表全表扫描本身就是微秒级开销，这个数值是正常的。
• 506ms的端到端耗时明显偏高，问题一定出在查询执行之外的外围环节，常见排查方向：
  • 验证是否是短连接开销导致：在同一个数据库会话里连续执行两次select * from table1，如果第二次耗时降到10ms以内，就说明是每次新建连接的开销导致的，建议改用连接池复用连接。
  • 验证网络开销：如果你的客户端连接的是远程数据库，可以用ping或者mtr工具测试到数据库IP的网络延迟，排查是否有链路抖动、丢包问题。
  • 验证客户端开销：如果用的是DBeaver、Navicat这类GUI数据库工具，可能存在结果渲染、日志打印的额外开销，可以换成psql原生命令行工具执行同样的查询对比耗时。
  • 验证锁等待：多次执行普通查询看耗时是否稳定，如果只有第一次查询慢，大概率是第一次执行时刚好遇到表上有写锁阻塞查询，后续锁释放后耗时就会恢复正常。

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