本文主要汇总了GaussDB(DWS)经常遇到的SQL语句执行慢问题处理方法。【重要提示】建议首先按照GaussDB(DWS)性能问题处理套路排查集群健康度、业务阻塞情况、业务并发和业务排队。本文重点介绍单个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 cant 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 ShippingFQSSQL语句会下发到DN上执行并且各DN之间没有数据交互常见的场景有过滤条件为等值查询where id 1或者关联的列是表的分布列的查询where t1.id t2.id。__REMOTE_LIGHT_QUERY__表明语句走了Light ProxyCN轻量化将语句下发给了单个DN去处理常见的场景过滤条件是分布列的等值查询where id 1或者向一个DN插入数据的INSERT语句。【案例2】表上有索引但没有走索引扫描进行了全表扫描从查询计划中可以看到Seq Scan或CStore Scan这样的关键字如下所示对于行存表- Seq Scan on t1对于列存表- CStore Scan on col_t1出现这种问题通常有以下几种情况没有对所查询的表收集统计信息如果表的实际行数很大而估算行数很小查询时可能会走全表顺序扫描造成执行速度慢。此时通过analyze表更新统计信息让优化器选择最佳的查询计划一般就可以解决执行慢的问题。【案例3】模糊匹配没有走索引后模糊匹配查询可以通过建立一个BTREE索引来实现需要根据数据类型设置索引的operator对于textvarchar和char分别设置和text_pattern_opsvarchar_pattern_ops和bpchar_pattern_ops。例如c1列的类型为text创建索引时增加text_pattern_ops。CREATE INDEX ON t1 (c1 text_pattern_ops);创建索引后可以看到语句执行时会使用到前面创建的索引执行速度会变快。【案例4】创建索引时所指定列的顺序问题多列复合索引的组织结构与单列字段索引结构类似按索引内表达式指定的顺序编排。当创建多列复合索引时选择什么样的列的顺序对查询性能会带来一定的影响。例如按照c_datec1和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后走并行查询。转载华为云论坛
GaussDB(DWS) SQL性能问题案例集
本文主要汇总了GaussDB(DWS)经常遇到的SQL语句执行慢问题处理方法。【重要提示】建议首先按照GaussDB(DWS)性能问题处理套路排查集群健康度、业务阻塞情况、业务并发和业务排队。本文重点介绍单个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 cant 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 ShippingFQSSQL语句会下发到DN上执行并且各DN之间没有数据交互常见的场景有过滤条件为等值查询where id 1或者关联的列是表的分布列的查询where t1.id t2.id。__REMOTE_LIGHT_QUERY__表明语句走了Light ProxyCN轻量化将语句下发给了单个DN去处理常见的场景过滤条件是分布列的等值查询where id 1或者向一个DN插入数据的INSERT语句。【案例2】表上有索引但没有走索引扫描进行了全表扫描从查询计划中可以看到Seq Scan或CStore Scan这样的关键字如下所示对于行存表- Seq Scan on t1对于列存表- CStore Scan on col_t1出现这种问题通常有以下几种情况没有对所查询的表收集统计信息如果表的实际行数很大而估算行数很小查询时可能会走全表顺序扫描造成执行速度慢。此时通过analyze表更新统计信息让优化器选择最佳的查询计划一般就可以解决执行慢的问题。【案例3】模糊匹配没有走索引后模糊匹配查询可以通过建立一个BTREE索引来实现需要根据数据类型设置索引的operator对于textvarchar和char分别设置和text_pattern_opsvarchar_pattern_ops和bpchar_pattern_ops。例如c1列的类型为text创建索引时增加text_pattern_ops。CREATE INDEX ON t1 (c1 text_pattern_ops);创建索引后可以看到语句执行时会使用到前面创建的索引执行速度会变快。【案例4】创建索引时所指定列的顺序问题多列复合索引的组织结构与单列字段索引结构类似按索引内表达式指定的顺序编排。当创建多列复合索引时选择什么样的列的顺序对查询性能会带来一定的影响。例如按照c_datec1和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后走并行查询。转载华为云论坛
