GoldenDB执行计划解读

基础技术研究 2024-03-13

344

点击上方蓝字·关注我们

GoldenDB是中兴通讯推出的一款分布式数据库，其出现为企业提高服务响应速度，提高系统的可靠性，起着重要的作用。执行计划是数据库用来执行SQL语句的内部逻辑和步骤的详细描述。理解并解读执行计划，可以帮助我们找到优化查询的关键。

为什么解读

GoldenDB，作为中兴通讯精心打造的分布式数据库产品，已在企业界引起广泛关注。其高效的性能与卓越的可靠性，为企业提供了前所未有的服务响应速度与系统稳定性。在数据库执行过程中，GoldenDB同样遵循业界标准，为每一条SQL语句生成详尽的执行计划。

执行计划，无疑是数据库优化过程中的关键一环。它详细记录了SQL语句在GoldenDB中的执行过程与访问路径，包括每一步的操作、涉及的数据表、使用的索引以及相应的成本估算等。这些信息，如同数据库内部的“导航图”，为我们提供了优化SQL语句、提升查询性能的宝贵线索。

解读GoldenDB的执行计划，无疑是一项需要细致与耐心的工作。我们需要深入理解每一个操作步骤的含义，分析数据表的访问方式是否高效，评估索引的使用是否得当，以及每个步骤的成本是否合理。通过这些分析，我们可以发现SQL语句中的性能瓶颈，进而进行针对性的优化。

值得注意的是，由于GoldenDB是一款分布式数据库，其执行计划可能相较于传统的集中式数据库更为复杂。分布式数据库的特性，如数据分片、节点间通信等，都会在执行计划中有所体现。因此，解读GoldenDB的执行计划，需要具备更为深厚的数据库知识与丰富的实践经验。

总的来说，GoldenDB的执行计划是我们优化SQL语句、提升数据库性能的重要工具。通过深入解读执行计划，我们可以发现潜在的性能问题，制定出有效的优化策略。同时，我们也需要不断积累数据库知识与实践经验，以更好地应对分布式数据库带来的挑战与机遇。

解读的方式

在业务应用场景中，深入了解SQL语句的执行过程对于性能优化至关重要。GoldenDB作为分布式数据库，其执行过程相较于传统集中式数据库更为复杂，因此获取CN（计算节点）和DN（数据节点）的执行信息显得尤为重要。

EXPLAIN命令是数据库提供的一个强大工具，它允许用户模拟优化器执行SQL语句的过程，从而揭示GoldenDB是如何处理SQL语句的。通过EXPLAIN+SQL语句的方式，用户可以获取到SQL语句的执行计划，这个执行计划详细描述了SQL语句在GoldenDB中的执行步骤、数据访问路径、操作成本等信息。

语法说明：

EXPLAIN [db|proxy] explainable_stmt [stroragedb] 
explainable_stmt: { 
SELECT statement 
| DELETE statement 
| INSERT statement 
| UPDATE statement 
}

用例：

例1：将分布式执行计划和DB执行计划结合输出。

EXPLAIN SELECT * FROM t1 WHERE id=1 or id=11 ORDER BY id;

例2：仅输出计算节点的分布式执行计划，此时需要PROXY选项。

EXPLAIN PROXY SELECT * FROM t1 WHERE id=1 or id=11 ORDER BY id;

例3：仅输出DB执行计划，此时需要使用DB选项，并指明要查看的存储节点。

EXPLAIN DB SELECT * FROM t1 WHERE id=1 or id=11 ORDER BY id STORAGEDB g2;

如何去解读

在GoldenDB分布式数据库中，表的数据通常是根据分片键（Sharding Key）进行水平切分的，这意味着相同分片键的数据会被存储在同一个数据节点（DN）上。当进行两表关联查询时，关联条件基于分片键和非分片键会有显著的性能和执行计划差异。

1、基于分片键的关联

当两表关联的条件是基于分片键时，GoldenDB可以高效地定位到需要参与关联的数据节点，并在这些节点上进行局部关联操作。这种情况下，通常只有少量的数据节点需要参与计算，网络传输的数据量也较少。该执行计划关键字select_type:SQLNode，当select_type为SQLNode时，CN层possible_keys语句展示为下发至DN层语句，CN层并未涉及关联匹配操作，这样会降低CN层CPU及内存消耗。

CN侧执行计划如下：

MySQL [hxbtest]> explain proxy SELECT a. * FROM test_200w_01 a left join test_2kw_01 b on  a.id =b.id\G
*************************** 1. row ***************************
id: 10001 --根节点标记10001,子节点依次加1，执行顺序由大到小，id相同并行执行。
select_type: SQLNode --CN层生成的节点类型，主要有JoinNode、UnionNode、SQLNode、MSQLNode节点。
table: 1--CN层节点编号，根节点为1，遍历查询各子节点值依次增加。
partitions: --CN层该字段为空。
type: --CN层该字段为空。
possible_keys:  SELECT `hxbtest`.`a`.`ID`,`hxbtest`.`a`.`int01`,`hxbtest`.`a`.`int02`,`hxbtest`.`a`.`int03`,`hxbtest`.`a`.`char01` FROM (`hxbtest`.`test_200w_01` `a` left join `hxbtest`.`test_2kw_01` `b` on((`hxbtest`.`a`.`id` = `hxbtest`.`b`.`id`))) ----当select_type=JoinNode, UnionNode 时为CN层关于节点的语句；当select_type=SQLNode, MSQLNode 时为下发DN语句。
key: Cluster1,g1,g2,g3,g4 ----当select_type=JoinNode, UnionNode是key=NULL;当select_type=SQLNode, MSQLNode时 key为下发group信息。
key_len:  --CN层该字段为空。
ref: Parent=NULL,Child=NULL,Next=NULL --父子节点信息。
rows: -- CN 层该字段为空。
filtered: -- CN 层该字段为空。
extra: ur, hxbtest.test_200w_01=hash,hxbtest.test_2kw_01=hash --隔离级别信息，表的分发信息。

2、基于非分片键的关联

当两表关联的条件不是基于分片键时，情况就变得复杂了。GoldenDB需要跨多个数据节点收集数据，并在计算节点（CN）进行全局关联操作。这通常涉及大量的数据传输和合并操作。该执行计划关键字select_type:JoinNode，当select_type为JoinNode时，CN层possible_keys语句展示为CN层语句。且出现子节点处理child0 = 2 child1 = 3，子节点select_type为SQLNode表示语句为下发至DN层处理，子节点处理完成后再执行父节点。CN层涉及语句拆分解析下发DN后，CN层关联匹配操作，这样会增加CN层CPU及内存消耗。

CN侧执行计划如下：

MySQL [hxbtest]> explain proxy SELECT a. * FROM test_200w_01 a left join test_2kw_01 b on  a.id =b.int01\G
*************************** 1. row ***************************
           id: 10001
  select_type: JoinNode --select_type为JoinNode
        table: 1
   partitions:
         type:
possible_keys:
id = 1
child0 = 2 child1 = 3 --涉及两个子节点
left join
table : (nest_last_join) --将两个数据集连接（join）起来的操作
on expr: (`hxbtest`.`b`.`int01` = `hxbtest`.`a`.`id`) --表达式
Involved tables : hxbtest.b hxbtest.a --参与表 
rowLen() : 0
id = 2, table = b --子节点处理信息
sort key : hxbtest.b.int01 --需要排序字段
involved tables : hxbtest.b --参与表
field list : hxbtest.b.int01 --处理列表
rowLen() : 0
id = 3, table = a --子节点处理信息
sort key : hxbtest.a.id --需要排序字段
involved tables : hxbtest.a --参与表
field list : hxbtest.a.id hxbtest.a.int01 hxbtest.a.int02 hxbtest.a.int03 hxbtest.a.char01 --处理列表
rowLen() : 0
          key: null
      key_len:
          ref: Parent=NULL,Child=2,3,Next=NULL --子节点
         rows:
     filtered:
        extra: ur,sort-merge
*************************** 2. row ***************************
展示子节点具体处理信息
           id: 10002
  select_type: SQLNode --select_type为SQLNode
        table: 2
   partitions:
         type:
possible_keys:  SELECT `hxbtest`.`b`.`int01` FROM `hxbtest`.`test_2kw_01` `b`    order by `hxbtest`.`b`.`int01` ASC --DN层执行语句
          key: Cluster1,g1,g2,g3,g4 --涉及租户信息及分片信息
      key_len:
          ref: Parent=1,Child=NULL,Next=3 --父节点与下一子节点
         rows:
     filtered:
        extra: ur,using sort, hxbtest.test_2kw_01=hash --隔离级别信息，表的分发信息。
*************************** 3. row ***************************
展示子节点具体处理信息
           id: 10002
  select_type: SQLNode --select_type为SQLNode
        table: 3
   partitions:
         type:
possible_keys:  SELECT `hxbtest`.`a`.`id`,`hxbtest`.`a`.`int01`,`hxbtest`.`a`.`int02`,`hxbtest`.`a`.`int03  FROM `hxbtest`.`test_200w_01` `a`    order by `hxbtest`.`a`.`id` ASC --DN层执行语句
          key: Cluster1,g1,g2,g3,g4 --涉及租户信息及分片信息
      key_len:
          ref: Parent=1,Child=NULL,Next=NULL --父节点
         rows:
     filtered:
        extra: ur,using sort, hxbtest.test_200w_01=hash --隔离级别信息，表的分发信息。

3、DN侧执行计划展示

GoldenDB由于完全兼容MySQL生态，在DN侧执行计划展示信息与MySQL较为相似，extra额外信息中会包含语句下发的分片信息，具体内容不做过多解释可参考公众号内文章《MySQL性能调优利器-Explain详解》。

MySQL [hxbtest]> explain DB SELECT a. * FROM test_200w_01 a left join test_2kw_01 b on  a.id =b.id STORAGEDB g1\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: a
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 8407733
     filtered: 100.00
        extra: NULL, g1
*************************** 2. row ***************************


           id: 1
  select_type: SIMPLE
        table: b
   partitions: NULL
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: hxbtest.a.ID
         rows: 1
     filtered: 100.00
        extra: Using index, g1

解读的意义

查看GoldenDB的执行计划的意义主要体现在以下几个方面：

1、性能优化：执行计划详细描述了数据库如何检索数据。通过分析执行计划，可以确定哪些操作最耗时，哪些索引最有效，从而找到性能瓶颈并进行优化。

2、理解查询执行过程：执行计划提供了查询的详细执行步骤，有助于开发人员和数据库管理员深入理解查询的执行过程，从而更好地理解和控制查询行为。

3、诊断问题：如果查询性能不佳，查看执行计划可以帮助诊断问题所在。例如，如果某个操作特别耗时，那么可能是该操作需要优化或需要添加合适的索引。

4、评估查询效率：通过比较不同查询的执行计划，可以评估它们的效率，从而选择更有效的查询策略。

总的来说，查看GoldenDB的执行计划对于理解数据库性能、优化查询和提高数据库效率具有重要意义。

参考文档：《ZXCLOUD_GoldenDB_分布式数据库SQL规范》

goldendb sql优化分布式数据库 select

文章转载自基础技术研究，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

GoldenDB执行计划解读

1、基于分片键的关联

评论