摘要:本文重点介绍单个SQL语句持续执行慢的场景。
本文分享自华为云社区《GaussDB(DWS) SQL性能问题案例集》,作者:黎明的风。
本文重点介绍单个SQL语句持续执行慢的场景。我们可以对执行慢的SQL进行单独分析,SELECT、INSERT、UPDATE等语句都可以使用explain verbose + SQL语句输出查询计划来进行分析,这样只输出查询计划,语句不会被实际的执行。
如果查询计划只出现__REMOTE_FQS_QUERY__或__REMOTE_LIGHT_QUERY__,看不到具体的计划,可以先执行set enable_fast_query_shipping to off; 然后再重新打印执行计划。
经常遇到的问题有以下几个:
【案例1】语句中包含不下推的函数
检查查询计划中是否包含_REMOTE_TABLE_QUERY_关键字, 如果有则表示语句没有下推,数据需要从DN上收取到CN上,然后语句在CN上执行。语句不下推原因,要从CN的日志中查找,搜索的关键字为:SQL can’t be shipped,以下为函数造成的不下推例子:
LOG: SQL can't be shipped, reason: Function Fun1() can not be shipped
此外如果出现以下几种不下推的关键字:__REMOTE_GROUP_QUERY__、__REMOTE_LIMIT_QUERY__、
__REMOTE_SORT_QUERY__。这种需要检查enable_stream_operator参数是否处于关闭状态,一般来说打开STREAM开关后,语句就可以下推执行了。
如果出现以下两种关键字,表示语句可以下推执行:
__REMOTE_FQS_QUERY__:表明语句走了Fast Query Shipping(FQS),SQL语句会下发到DN上执行,并且各DN之间没有数据交互,常见的场景有过滤条件为等值查询(where id = 1),或者关联的列是表的分布列的查询(where t1.id = t2.id)。
__REMOTE_LIGHT_QUERY__:表明语句走了Light Proxy(CN轻量化),将语句下发给了单个DN去处理,常见的场景过滤条件是分布列的等值查询(where id = 1),或者向一个DN插入数据的INSERT语句。
【案例2】表上有索引但没有走索引扫描,进行了全表扫描
从查询计划中可以看到Seq Scan或CStore Scan这样的关键字,如下所示:
对于行存表:-> Seq Scan on t1
对于列存表:-> CStore Scan on col_t1
出现这种问题通常有以下几种情况:
没有对所查询的表收集统计信息
如果表的实际行数很大,而估算行数很小,查询时可能会走全表顺序扫描,造成执行速度慢。此时通过analyze表更新统计信息,让优化器选择最佳的查询计划,一般就可以解决执行慢的问题。
【案例3】模糊匹配没有走索引
后模糊匹配查询可以通过建立一个BTREE索引来实现,需要根据数据类型设置索引的operator,对于text,varchar和char分别设置和text_pattern_ops,varchar_pattern_ops和bpchar_pattern_ops。
例如c1列的类型为text,创建索引时增加text_pattern_ops。
CREATE INDEX ON t1 (c1 text_pattern_ops);
创建索引后,可以看到语句执行时会使用到前面创建的索引,执行速度会变快。
【案例4】创建索引时所指定列的顺序问题
多列复合索引的组织结构与单列字段索引结构类似,按索引内表达式指定的顺序编排。当创建多列复合索引时,选择什么样的列的顺序,对查询性能会带来一定的影响。
例如按照c_date,c1和c2列的顺序建立检索,如果符合c_date条件的数据很多,通过这个索引扫描的数据就很会很多,造成执行时间长。
新建多列复合索引,将查询条件里的等值条件的列放到索引列的前面,先使用等值进行过滤,需要扫描的数据变少,查询变快。
【案例5】分区表没有分区剪枝进行了全表扫描
问题背景:XSYX局点使用MERGE INTO语句将每天的数据入库到表里,目标表为分区表,业务上线运行一段时间后发现MERGE INTO速度逐渐变慢。
原因分析:MERGE INTO语句的源表和目标表都是分区表,当前仅对源表增加了时间的过滤条件,可以进行分区剪枝。目标表由于没有指定时间过滤条件,进行的是全表扫描,随着每日的入库业务运行,目标表的数据量越来越大,造成执行速度越来越慢。
解决方案:由于源表的数据在MERGE INTO时会导入到目标表的对应分区里,可以对目标表增加时间的过滤条件进行分区剪枝。
业务修改前的查询计划:
对目标表增加了时间过滤条件后的计划显示可以走分区剪枝:
【案例6】表数据在DN节点上有存储倾斜
从查询计划中的A-time可以看到最长和最短的执行时间相差很大,说明在不同DN上扫描数据的时间不同。
在查询计划的DN信息中,通过rows可以看出在datanode1上扫描的数据量明显多于datanode2,说明有存储倾斜,这种情况建议对表进行合理的设计,选择合适的分布列,将数据均匀分布到所有的DN上。
【案例7】自定义函数引起执行慢
问题现象:查询语句比较简单,两个表做关联后输出了其中一列的值,在输出前增加了一个自定义函数对数据进行了处理。
原因分析:自定义函数里逻辑相对复杂,包含了对表的查询及数据计算逻辑,造成执行变慢。
解决方案;业务上对自定义函数进行性能优化。
【案例8】查询视图执行时间长
问题现象:某YD局点从C80版本迁移数据到8.1.1版本后,查询PG_STAT_USER_TABLES视图的时间由几分钟变成半个小时都不出结果。
原因分析:8.1.1版本中的PG_STAT_USER_TABLES视图在获取插入、更新、删除的行数的字段数值时,每一条记录都涉及到CN和DN的交互,在数据量和集群规模大的情况下耗时较多。
解决方案:建议根据应用的实际需要,将视图定义中不需要的函数注释掉以提升查询效率。
【案例9】关闭indexscan和bitmapscan后可以使用并行提升性能
问题现象: 查询计划中显示走了Index Scan,通过索引查询出的数据量比较大,速度慢。
原因分析:由于使用索引扫描时无法使用并行查询,当索引访问的数据量大时执行速度较慢。
解决方案:将enable_indexscan和enable_bitmapscan参数关闭,设置query_dop后走并行查询。