博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SQL慢查询在Greenplum/Deepgreen中的定位方法
阅读量:5822 次
发布时间:2019-06-18

本文共 1206 字,大约阅读时间需要 4 分钟。

  hot3.png

在生产过程中,有的SQL查询往往会变得越来越慢,这时候,我们该怎么办呢?首当其冲的,我们可以通过查询计划来定位问题,今天就来谈谈如何在查询计划中定位这些慢查询产生的原因。

1.查询计划中是否有操作耗时特别的长?

当我们分析查询计划时,是否有一个异常操作消耗了大部分的查询时间?比如,在执行索引扫描时,时间比预期的要长很多,这时候我们基本可以判断此索引可能已经超期了,需要重建。

2.查询计划预估的时间和真实的时间接近吗?

我们通过运行EXPLAIN ANALYZE,查看执行计划预估的返回行数与实际返回的行数是否接近,如果出入很大,说明统计信息是有问题的,我们需要对相关表/列收集更多的统计信息。

3.选择语句中的限定条件是否生效更早?

在执行计划中,选择性限定条件应该更早的应用,目的是让更少的数据返回到上层操作中。如果查询在选择性限定条件应用后表现并不好,返回的消耗依然很大,我们可以收集相关列的统计信息再看看是否会提高性能;另外,还可以通过调整SQL语句中不合理的WHERE条件来提高性能。

4.查询计划是否选择了最佳的JOIN顺序?

当我们的查询里面有很多连接操作(JOIN)时,要确保执行计划选择了一个最优连接顺序。拥有大量返回数据的连接应该尽早完成,以保证我们为上层操作返回更少的行。如果执行计划没有选择最佳的连接顺序,我们可以设置参数join_collapse_limit=1,然后在SQL语句中使用明确的JOIN语法强迫执行计划按照特定的执行顺序执行。另外,我们可以收集相关列的统计信息再看看是否会提高性能。

5.查询计划是否有选择性的扫描分区表?

如果我们使用查询中涉及到了分区表数据查询,那么查询计划是否直接定位到扫描满足条件的分区,而不是扫描整张表。

6.查询计划是否适当的选择Hash Aggregate和Hash Join操作?

Hash操作比其他类型的聚合或者连接操作要快很多,行数据的比较和分类操作是在内存中进行,而不是通过读写磁盘完成。为了能够使用Hash操作,我们必须保证有足够的work memory可以容纳查询计划返回的行数据,所以我们可以通过尝试增加work memory来提高查询性能。通过运行EXPLAIN ANALYZE命令,这样可以看出哪些计划会有数据使用到磁盘,需要多少额外的work memory等,为work memory的调整提供参考。例如:

Work_mem used: 23430K bytes avg, 23430K bytes max (seg0).Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen workfile I/O affecting 2 workers.

转载于:https://my.oschina.net/javacy/blog/1486617

你可能感兴趣的文章
UIImagePickerController拍照与摄像
查看>>
python调用windows api
查看>>
第四章 mybatis批量insert
查看>>
Java并发框架——什么是AQS框架
查看>>
【数据库】
查看>>
Win配置Apache+mod_wsgi+django环境+域名
查看>>
linux清除文件内容
查看>>
WindowManager.LayoutParams 详解
查看>>
find的命令的使用和文件名的后缀
查看>>
Android的Aidl安装方法
查看>>
Linux中rc的含义
查看>>
曾鸣:区块链的春天还没有到来| 阿里内部干货
查看>>
如何通过Dataworks禁止MaxCompute 子账号跨Project访问
查看>>
js之无缝滚动
查看>>
Django 多表联合查询
查看>>
logging模块学习:basicConfig配置文件
查看>>
Golang 使用 Beego 与 Mgo 开发的示例程序
查看>>
ntpdate时间同步
查看>>
+++++++子域授权与编译安装(一)
查看>>
asp.net怎样在URL中使用中文、空格、特殊字符
查看>>