本文介绍一种稍微隐蔽一点的性能问题，反映出来的特点就是SQL执行出现大面积的慢，即使是简单的 select 查询，依然如此。而且是首次慢，紧接着再执行第二次就快了。具体怎么回事儿呢？
前言
这是在实际工作中遇到的问题，一开始从慢SQL查起，确实优化了一些执行缓慢的多表join的SQL语句。直到后来发现就连简单的SQL查询也是同样问题，才知道排查的方向错了。
首先看系统状态，CPU使用率是正常的。接着看磁盘IO，终于发现问题了，是磁盘IO使用率太高了。有了这个线索，很快就定位到了原因。原因是，有多个大表在全表扫描，因为数据量大，执行了太长时间。导致磁盘IO占满了。再有新的请求自然就很慢了。
回到本文的主题，如何通过 pg_stat_statements 来先发现端倪呢？
排查方法
我们可以通过查询 pg_stat_statements 视图相关字段来确认这一情况。
下面给出一个通用模板，大家在实际使用时，可以根据需求来调整排序字段、新增查询字段等。
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 值是否异常。
查看命令如下：
iostat -x -d 1
结果示例
Device r/s rkB/s ... %util
sdd 0.00 0.00 ... 98.3
记录耗时（可选）
读取共享块耗时默认是不统计的，如果确认需要这个字段可以通过配置开启。
启用配置
# postgresql.conf
track_io_timing = on # 默认 off
总结
全表扫描会导致IO问题，很多大表的全表扫描会将IO使用率打满，导致后面的SQL执行变慢。于是，本文前面描述的症状就出现了。
数据库设计不当、时间拉长后数据量增多都会出现此类问题。通过这两篇的介绍，大家一定都入门了，后面就是用起来吧，多观察和优化。避免影响实际业务。
大家是否遇到此类问题呢？
评论区聊聊。
