PG 慢查询优化

    下面以Pigsty自带的沙箱环境为例，介绍一个使用Pigsty监控系统处理慢查询的过程。

    因为没有实际的业务系统，这里我们以一种简单快捷的方式模拟系统中的慢查询。即pgbench自带的。

    在主库上执行以下命令

    该命令会移除 pgbench_accounts 表上的主键，导致相关查询变慢，系统瞬间雪崩过载。

    PG 慢查询优化 - 图2

    图2：系统负载达到200%，触发机器负载过大，与查询响应时间过长的报警规则。

    首先，使用PG Cluster面板定位慢查询所在的具体实例，这里以 pg-test-2为例

    然后，使用面板定位具体的慢查询：编号为 -6041100154778468427

    该查询表现出：

    • QPS 显著下降： 从500下降到 7
    • 花费在该查询上的时间占比显著增加

    可以确定，就是这个查询变慢了！

    接下来，利用PG Stat Statements面板或，根据查询ID定位慢查询的具体语句。

    PG 慢查询优化 - 图4

    接下来，我们需要推断慢查询产生的原因。

      该查询以 作为过滤条件查询 pgbench_accounts 表，如此简单的查询变慢，大概率是这张表上的索引出了问题。

      用屁股想都知道是索引少了，因为就是我们自己删掉的嘛！

      分析查询后提出猜想： 该查询变慢是pgbench_accounts表上列缺少索引

      下一步，查阅 面板，检查 pgbench_accounts 表上的访问，来验证我们的猜想

      通过观察，我们发现表上的索引扫描归零，与此同时顺序扫描却有相应增长。这印证了我们的猜想！

      确定了问题根源后，我们将着手解决。

      尝试在 表上为 aid 列添加索引，看看能否解决这个问题。

      加上索引后，神奇的事情发生了。

      PG 慢查询优化 - 图6

      图7：系统的负载也恢复正常

      通过这篇教程，您已经掌握了慢查询优化的一般方法论。

      PG 慢查询优化 - 图8

      图8：一个慢查询优化的实际例子，将系统的饱和度从40%降到了4%