SQL自诊断

告警场景

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

• 多列/单列统计信息未收集

  如果存在单列或者多列统计信息未收集，则上报相关告警。对于这种告警，建议的优化方案是对相关表进行ANALYZE，可参考更新统计信息和统计信息调优。

  需要特别注意的是，如果查询语句中的OBS外表和HDFS外表未收集统计信息，也会上报统计信息未收集的告警，因为OBS外表和HDFS外表的ANALYZE的性能比较差，一般不建议对其进行ANALYZE，但是建议使用ALTER FOREIGN TABLE的语法修改外表的totalrows属性，从而修正外表的行数估算。

  告警信息示例：

  整表的统计信息未收集：

  Statistic Not Collect
          schema_test.t1

  单列统计信息未收集：

  Statistic Not Collect
          schema_test.t2(c1)

  多列统计信息未收集:

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

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

  Statistic Not Collect
          schema_test.t4(c1)
          schema_test.t5((c1,c2))

• 分区不剪枝（该功能仅8.1.2及以上版本支持）

  分区表查询时，常会期望通过分区键上的约束条件进行分区剪枝，从而提升分区表查询性能，但有时候会因为约束条件书写不当，导致分区表没有剪枝，出现查询性能问题，具体请参见案例：改写SQL排除剪枝干扰。

• SQL不下推

  对于不下推的SQL，尽可能详细上报导致不下推的原因。调优方法可参考案例语句下推调优。

  导致不下推的因素主要有以下两点：

  • 函数导致的不下推

    诊断信息中会给出具体的函数名称。函数下推是由函数的shippable属性决定，具体可参见CREATE FUNCTION语法。

  • 语法导致的不下推

    诊断信息中会提示导致不下推的具体语法，例如：含有With Recursive，Distinct On，row表达式，返回值为record类型的，会告警相应语法不支持下推等等。

  告警信息示例：

  SQL is not plan-shipping 
          "enable_stream_operator" is off
  
  SQL is not plan-shipping 
          "Distinct On" can not be shipped
  
  SQL is not plan-shipping
          "v_test_unshipping_log" is VIEW that will be treated as Record type can't be shipped

• HashJoin中大表做内表

  如果在表连接过程中使用了Hashjoin（可通过GS_WLM_SESSION_HISTORY的“query_plan”字段查看），且连接的内表行数是外表行数的10倍或以上；同时内表在每个DN上的平均行数大于10万行，且发生了下盘，则上报相关告警。针对这种场景，需要调整HashJoin内外表顺序，具体调优方法参考Join顺序的Hint。

  告警信息示例：

  Execute diagnostic information
          PlanNode[7] Large Table is INNER in HashJoin “Vector Hash Aggregate”

  其中，7为“query_plan”字段文本中编号为7的算子。

• 大表等值连接使用Nestloop

  如果在表连接过程中使用了nestloop（可通过GS_WLM_SESSION_HISTORY的query_plan字段查看），并且两个表中较大表的行数平均每个DN上的行数大于10万行、表的连接中存在等值连接，则上报相关告警。针对这种场景，需要调整表关联方式，禁止当前内外表之间使用NestLoop的关联方式，具体调优方法参考Join方式的Hint。

  告警信息示例：

  Execute diagnostic information
          PlanNode[5] Large Table with Equal-Condition use Nestloop"Nested Loop"

• 大表Broadcast

  如果在Broadcast算子中，平均每DN的行数大于10万行，则告警大表Broadcast。针对这种场景，需要禁止Broadcast下层算子做Broadcast动作，具体调优方法参考Stream方式的Hint。

  告警信息示例：

  Execute diagnostic information
          PlanNode[5] Large Table in Broadcast "Streaming(type: BROADCAST dop: 1/2)"

• 数据倾斜

  某表在各DN上的分布，存在某DN上的行数是另一DN上行数的10倍或以上，且有DN中的行数大于10万行，则上报相关告警。该告警一般分为存储层倾斜和计算层倾斜，具体调优方法参考数据倾斜调优。

  告警信息示例：

  Execute diagnostic information
         PlanNode[6] DataSkew:"Seq Scan", min_dn_tuples:0, max_dn_tuples:524288

• 索引不合理

  在基表扫描时，满足下述条件则上报相关告警：

  • 对于行存表：
    • 使用索引扫描，输出行数/扫描行数>1/1000且输出行数>1万行。
    • 使用顺序扫描，输出行数/扫描行数<1/1000且输出行数<=1万行、扫描行数>1万行。
  • 对于列存表：
    • 使用索引扫描，输出行数/扫描行数>1/10000且输出行数>100。
    • 使用顺序扫描，输出行数/扫描行数<1/10000且输出行数<=100、扫描行数>1万行。

  调优方法可参考算子级调优，也可参考案例案例：建立合适的索引和案例：使用partial cluster key。

  告警信息示例：

  Execute diagnostic information
          PlanNode[4] Indexscan is not properly used:"Index Only Scan", output:524288, filtered:0, rate:1.00000
          PlanNode[5] Indexscan is ought to be used:"Seq Scan", output:1, filtered:524288, rate:0.00000

  需要注意的是，这个诊断结果只是针对当前SQL的建议，是否创建索引要结合整体业务综合分析，对于高频的过滤条件才建议创建索引。

• 估算不准

  对于平均每DN行数如果优化器的估算行数和实际行数中的较大值大于10万行，并且估算行数和实际行数中较大值是较小值的10倍或以上，则上报相关告警。针对这种场景，可以参照行数的Hint修正行数估算，让优化器在正确的行数基础上重新规划执行计划。

  告警信息示例：

  Execute diagnostic information
          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等其他算子很可能也出现数据倾斜。