PostgreSQL pg_stat_statements 性能分析利器（二）全表扫描导致物理IO爆炸

本文介绍一种稍微隐蔽一点的性能问题，反映出来的特点就是SQL执行出现大面积的慢，即使是简单的 select 查询，依然如此。而且是首次慢，紧接着再执行第二次就快了。具体怎么回事儿呢？

前言

这是在实际工作中遇到的问题，一开始从慢SQL查起，确实优化了一些执行缓慢的多表join的SQL语句。直到后来发现就连简单的SQL查询也是同样问题，才知道排查的方向错了。

首先看系统状态，CPU使用率是正常的。接着看磁盘IO，终于发现问题了，是磁盘IO使用率太高了。有了这个线索，很快就定位到了原因。原因是，有多个大表在全表扫描，因为数据量大，执行了太长时间。导致磁盘IO占满了。再有新的请求自然就很慢了。

回到本文的主题，如何通过 pg_stat_statements 来先发现端倪呢？

排查方法

我们可以通过查询 pg_stat_statements 视图相关字段来确认这一情况。

下面给出一个通用模板，大家在实际使用时，可以根据需求来调整排序字段、新增查询字段等。

sql 复制代码

SELECT
    queryid,
    query,
    calls AS 执行次数,
    shared_blks_read AS 物理读块数,
    shared_blks_hit AS 缓存命中块数,
    round(shared_blks_hit::numeric / NULLIF(shared_blks_hit + shared_blks_read, 0) * 100, 2) AS 缓存命中率,
    round(shared_blk_read_time::numeric  / 1000, 2) AS 磁盘读取耗时_s,
    round(total_exec_time::numeric / 1000, 2) AS SQL总耗时_s,
    round(total_exec_time::numeric / calls / 1000, 2) AS 单次执行耗时_s
FROM pg_stat_statements
WHERE shared_blks_read > 0
  AND calls > 0
ORDER BY shared_blks_read DESC, total_exec_time DESC
LIMIT 10;

执行结果示例：

字段含义不难理解，大家对照字段别名和取值字段观察分析即可。

确认IO问题

仅仅通过以上SQL是不能确认磁盘IO使用率爆满导致的响应缓慢。

实际上想要将使用率打满也是不容易的。

最后确认还是要通过操作系统命令来查看，确认 %util 值是否异常。

查看命令如下：

bash 复制代码

iostat -x -d 1

结果示例

plain 复制代码

Device            r/s     rkB/s   ...  %util
sdd              0.00      0.00     ...   98.3

记录耗时（可选）

读取共享块耗时默认是不统计的，如果确认需要这个字段可以通过配置开启。

启用配置

ini 复制代码

# postgresql.conf

track_io_timing = on # 默认 off

总结

全表扫描会导致IO问题，很多大表的全表扫描会将IO使用率打满，导致后面的SQL执行变慢。于是，本文前面描述的症状就出现了。

数据库设计不当、时间拉长后数据量增多都会出现此类问题。通过这两篇的介绍，大家一定都入门了，后面就是用起来吧，多观察和优化。避免影响实际业务。

大家是否遇到此类问题呢？

评论区聊聊。

参考

PostgreSQL: Documentation: 18: F.32. pg_stat_statements --- track statistics of SQL planning and execution