高斯数据库 (gaussDB) - SQL 调优指南 (5)

典型 SQL 调优点

SQL 自诊断

用户在执行查询或者执行 INSERT/DELETE/UPDATE/CREATE TABLE AS 语句时,可能
会遇到性能问题。这种情况下,通过查询 gs_wlm_session_statistics,
gs_wlm_session_history,gs_wlm_session_info 视图的 warning 字段可以获得对应查询可
能导致性能问题的告警信息,为性能调优提供参考。
SQL 自诊断的告警类型与 resource_track_level 的设置有关系。如果 resource_track_level
设置为 query,则可以诊断多列 / 单列统计信息未收集和 SQL 不下推的告警。如果
resource_track_level 设置为 operator,则可以诊断所有的告警场景。
SQL 自诊断的诊断范围与 resource_track_cost 的设置有关系。当 SQL 的代价大于
resource_track_cost 时,SQL 才会被诊断。SQL 的代价可以通过 explain 来确认。

告警场景

目前支持对以下 7 种导致性能问题的场景上报告警。

  • 多列 / 单列统计信息未收集
    如果存在单列或者多列统计信息未收集,则上报相关告警。调优方法可以参考 更新统
    计信息和 统计信息调优。
    需要特别注意的是,对于基于 OBS 外表和 HDFS 外表的查询,如果未收集统计信息也会
    上报统计信息未收集的告警,但是由于 OBS 外表和 HDFS 外表的 analyze 的性能比较差,
    因此,需要用户对这种场景下告警是否通过 analyze 收集统计信息,以获取更优的性
    能,和查询本身的复杂度做权衡。
    告警信息示例:
    整表的统计信息未收集:
Statistic Not Collect:
schema_test.t1

单列统计信息未收集:

Statistic Not Collect:
schema_test.t2(c1,c2)

多列统计信息未收集:

Statistic Not Collect:
schema_test.t3((c1,c2))

单列和多列统计信息未收集:

Statistic Not Collect:
schema_test.t4(c1,c2) schema_test.t4((c1,c2))
  • SQL 不下推
    对于不下推的 SQL,尽可能详细上报导致不下推的原因。调优方法可以参考案例
    语句下推调优。
    – 对于函数导致的不下推,告警导致不下推的函数名信息;
    – 对于不支持下推的语法,会告警对应语法不支持下推,例如:含有 With
    Recursive,Distinct On,row 表达式,返回值为 record 类型的,会告警相应语
    法不支持下推等等。
    告警信息示例:
SQL is not plan-shipping, reason : "With Recursive" can not be shipped"
SQL is not plan-shipping, reason : "Function now() can not be shipped"
SQL is not plan-shipping, reason : "Function string_agg() can not be shipped"
  • HashJoin 中大表做内表
    如果在表连接过程中使用了 Hashjoin( 可以在 gs_wlm_session_history 的 query_plan 字段中
    查看到 ),且连接的内表行数是外表行数的 10 倍或以上;同时内表在每个 DN 上的平均行
    数大于 10 万行,且发生了下盘,则上报相关告警。调优方法可以参考 使用 plan hint 调
    优执行计划。
    告警信息示例:
    PlanNode[7] Large Table is INNER in HashJoin “Vector Hash Aggregate”
  • 大表等值连接使用 Nestloop
    如果在表连接过程中使用了 nestloop( 可以在 gs_wlm_session_history 的 query_plan 字段中
    查看到 ),并且两个表中较大表的行数平均每个 DN 上的行数大于 10 万行、表的连接中存
    在等值连接,则上报相关告警。调优方法可以参考 使用 plan hint 调优执行计划。
    告警信息示例:
    PlanNode[5] Large Table with Equal-Condition use Nestloop"Nested Loop"
  • 大表 Broadcast
    如果在 Broadcast 算子中,平均每 DN 的行数大于 10 万行,则告警大表 broadcast。调优方
    法可以参考 使用 plan hint 调优执行计划。
    告警信息示例:
    PlanNode[5] Large Table in Broadcast "Streaming(type: BROADCAST dop: 1/2)"
  • 数据倾斜
    某表在各 DN 上的分布,存在某 DN 上的行数是另一 DN 上行数的 10 倍或以上,且有 DN 中
    的行数大于 10 万行,则上报相关告警。调优方法可以参考案例 选择合适的分布列和 数
    据倾斜调优。
    告警信息示例:
    PlanNode[6] DataSkew:"Seq Scan", min_dn_tuples:0, max_dn_tuples:524288
  • 估算不准
    如果优化器的估算行数和实际行数中的较大值平均每 DN 行数大于 10 万行,并且估算行
    数和实际行数中较大值是较小值的 10 倍或以上,则上报相关告警。调优方法可以参考
    使用 plan hint 调优执行计划。
    告警信息示例:
    PlanNode[5] Inaccurate Estimation-Rows: "Hash Join" A-Rows:0, E-Rows:52488

规格约束

  1. 告警字符串长度上限为 2048。如果告警信息超过这个长度(例如存在大量未收集
    统计信息的超长表名,列名等信息)则不告警,只上报 warning:
    WARNING, “Planner issue report is truncated, the rest of planner issues will be skipped”
  2. 如果 query 存在 limit 节点(即查询语句中包含 limit),则不会上报 limit 节点以下的
    Operator 级别的告警。
  3. 对于“数据倾斜”和“估算不准”两种类型告警,在某一个 plan 树结构下,只上报
    下层节点的告警,上层节点不再重复告警。这主要是因为这两种类型的告警可能
    是因为底层触发上层的。例如,如果在 scan 节点已经存在数据倾斜,那么在上层
    的 hashagg 等其他算子很可能也出现数据倾斜。

  
    展开阅读全文