KingbaseES 查询计划剖析

概述：了解KingbaseES查询计划对于开发人员和数据库管理员来说都是一项关键技能。这可能是优化SQL查询的第一件事，也是验证优化的SQL查询是否确实实现期望结果的方式。

1、KingbaseES数据库中的查询生命周期

每个查询都会经历不同的阶段，了解下面周期的每个阶段，对理解数据库是很重要的。

 

第一阶段是通过JDBC/ODBC或通过其他方式如KSQL（客户端工具）连接到数据库。

第二阶段是将查询转换为解析树的格式，就像 SQL 查询的编译形式。

第三阶段是重写系统/规则系统。它采用从第二阶段生成的解析树，并以规划器/优化器可以开始在其中工作的方式重写它。

第四阶段是最重要数据库的核心。规划器使得知执行器知道如何执行查询、使用什么索引、是否扫描较小的表以消除更多不必要的记录等问题。

第五个也是最后一个阶段是执行器，它执行实际执行并返回结果。

下面将描述第四阶段的工作内容。

2、数据设置

首先建立一些表来运行本文的实验。

?
1
CREATE TABLE TEST_TABLE AS select id, lpad(id,10,'0') code, md5(random()) name from generate_series(1, 1000000) id;

该表现在包含1000000行记录。

下面的大多数示例将基于上表。有意保持简单，专注于过程而不是表/数据的复杂性。

3、KingbaseES解释一个查询

 explain select * from test_table limit 10;

?
1
2
3
4
5
6
test=# explain select * from test_table limit 10;
                                QUERY PLAN
--------------------------------------------------------------------------
 Limit  (cost=0.00..0.22 rows=10 width=68)
   ->  Seq Scan on test_table  (cost=0.00..17196.64 rows=785064 width=68)
(2 rows)

通过使用EXPLAIN，可以在数据库实际执行查询计划之前查看它们。将在下面的部分中了解每一个的部分，先看看另一个扩展版本的EXPLAIN调用EXPLAIN ANALYZE。

 explain analyze select * from test_table limit 10;

?
1
2
3
4
5
6
7
8
test=# explain analyze select * from test_table limit 10;
                                                     QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..0.22 rows=10 width=68) (actual time=0.062..0.063 rows=10 loops=1)
   ->  Seq Scan on test_table  (cost=0.00..17196.64 rows=785064 width=68) (actual time=0.060..0.061 rows=10 loops=1)
 Planning Time: 0.064 ms
 Execution Time: 0.073 ms
(4 rows)

与 不同EXPLAIN，EXPLAIN ANALYSE实际上在数据库中运行查询。这个选项对于了解计划者是否没有正确发挥其作用非常有帮助；即，从EXPLAIN和生成的计划是否存在巨大差异EXPLAIN ANALYZE。

4、什么是数据库中的缓冲区和缓存？

这里讨论一个有意义的指标BUFFERS。它解释了有多少数据来自缓存，以及有多少必须从磁盘中获取。

explain (analyze,buffers) select * from test_table limit 10 offset 20;

?
1
2
3
4
5
6
7
8
9
test=# explain (analyze,buffers) select * from test_table limit 10 offset 20;
                                                      QUERY PLAN
----------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.39..0.58 rows=10 width=48) (actual time=0.008..0.009 rows=10 loops=1)
   Buffers: shared hit=1
   ->  Seq Scan on test_table  (cost=0.00..19346.00 rows=1000000 width=48) (actual time=0.005..0.007 rows=30 loops=1)
         Buffers: shared hit=1
 Planning Time: 0.100 ms
 Execution Time: 0.019 ms

Buffers : shared hit=1意味着从 KingbaseES缓存本身获取了1个页面。

explain (analyze,buffers) select * from test_table limit 100 offset 500;

?
1
2
3
4
5
6
7
8
9
test=# explain (analyze,buffers) select * from test_table limit 100 offset 500;
                                                      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Limit  (cost=9.67..11.61 rows=100 width=48) (actual time=0.140..0.157 rows=100 loops=1)
   Buffers: shared hit=1 read=5
   ->  Seq Scan on test_table  (cost=0.00..19346.00 rows=1000000 width=48) (actual time=0.008..0.134 rows=600 loops=1)
         Buffers: shared hit=1 read=5
 Planning Time: 0.039 ms
 Execution Time: 0.171 ms

Buffers: shared hit=1 read=5，显示5个页面来自磁盘。该read部分是显示有多少页面来自磁盘的变量，hit表示来自缓存。如果我们再次执行相同的查询（记住ANALYSE运行查询），那么所有数据现在都来自缓存。

 

?
1
2
3
4
5
6
7
8
9
10
test=# explain (analyze,buffers) select * from test_table limit 100 offset 500;
                                                      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Limit  (cost=9.67..11.61 rows=100 width=48) (actual time=0.058..0.070 rows=100 loops=1)
   Buffers: shared hit=6
   ->  Seq Scan on test_table  (cost=0.00..19346.00 rows=1000000 width=48) (actual time=0.009..0.047 rows=600 loops=1)
         Buffers: shared hit=6
 Planning Time: 0.040 ms
 Execution Time: 0.084 ms
(6 rows)

　　

KingbaseES使用一种称为 LRU（最近最少使用）缓存的机制将经常使用的数据存储在内存中。了解到 KingbaseES 的缓存机制，可以使用EXPLAIN (ANALYSE, BUFFERS)命令查看它是如何工作的。

5、VERBOSE 命令参数

Verbose 是另一个提供额外信息的命令参数。

explain (analyze,buffers,verbose) select * from test_table limit 100 offset 500;

 

?
1
2
3
4
5
6
7
8
9
10
11
test=# explain (analyze,buffers,verbose) select * from test_table limit 100 offset 500;
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=9.67..11.61 rows=100 width=48) (actual time=0.101..0.115 rows=100 loops=1)
   Output: id, code, name
   Buffers: shared hit=6
   ->  Seq Scan on public.test_table  (cost=0.00..19346.00 rows=1000000 width=48) (actual time=0.008..0.091 rows=600 loops=1)
         Output: id, code, name
         Buffers: shared hit=6
 Planning Time: 0.034 ms
 Execution Time: 0.129 ms

　　

注意，Output: id, code, name是附加的。在复杂的查询计划中，将打印大量其他信息。默认情况下，COSTS and TIMING选项TRUE作为设置，除非您想将它们设置为FALSE。

6、KingbaseES中的 FORMAT 解释

KingbaseES能够以多种格式提供查询计划，例如JSON，这些计划可以用某种语言进行解析。

explain (analyze,buffers,verbose,format json) select * from test_table limit 100 offset 5000;

 

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
test=# explain (analyze,buffers,verbose,format json) select * from test_table limit 100 offset 5000;
                 QUERY PLAN
---------------------------------------------
 [                                          +
   {                                        +
     "Plan": {                              +
       "Node Type": "Limit",                +
       "Parallel Aware": false,             +
       "Startup Cost": 96.73,               +
       "Total Cost": 98.66,                 +
       "Plan Rows": 100,                    +
       "Plan Width": 48,                    +
       "Actual Startup Time": 0.802,        +
       "Actual Total Time": 0.821,          +
       "Actual Rows": 100,                  +
       "Actual Loops": 1,                   +
       "Output": ["id", "code", "name"],    +
       "Shared Hit Blocks": 6,              +
       "Shared Read Blocks": 42,            +
       "Shared Dirtied Blocks": 0,          +
       "Shared Written Blocks": 0,          +
       "Local Hit Blocks": 0,               +
       "Local Read Blocks": 0,              +
       "Local Dirtied Blocks": 0,           +
       "Local Written Blocks": 0,           +
       "Temp Read Blocks": 0,               +
       "Temp Written Blocks": 0,            +
       "Plans": [                           +
         {                                  +
           "Node Type": "Seq Scan",         +
           "Parent Relationship": "Outer",  +
           "Parallel Aware": false,         +
           "Relation Name": "test_table",   +
           "Schema": "public",              +
           "Alias": "test_table",           +
           "Startup Cost": 0.00,            +
           "Total Cost": 19346.00,          +
           "Plan Rows": 1000000,            +
           "Plan Width": 48,                +
           "Actual Startup Time": 0.006,    +
           "Actual Total Time": 0.646,      +
           "Actual Rows": 5100,             +
           "Actual Loops": 1,               +
           "Output": ["id", "code", "name"],+
           "Shared Hit Blocks": 6,          +
           "Shared Read Blocks": 42,        +
           "Shared Dirtied Blocks": 0,      +
           "Shared Written Blocks": 0,      +
           "Local Hit Blocks": 0,           +
           "Local Read Blocks": 0,          +
           "Local Dirtied Blocks": 0,       +
           "Local Written Blocks": 0,       +
           "Temp Read Blocks": 0,           +
           "Temp Written Blocks": 0         +
         }                                  +
       ]                                    +
     },                                     +
     "Planning Time": 0.058,                +
     "Triggers": [                          +
     ],                                     +
     "Execution Time": 0.835                +
   }                                        +
 ]
(1 row)

　　

同时还支持其他格式：TEXT（默认）、JSON、XML、YAML

7、总结EXPLAIN使用方式

EXPLAIN 通常会开始使用的计划类型，主要用于生产系统。

EXPLAIN ANALYSE用于运行查询以及获取查询计划。这是获得计划中的计划时间和执行时间细分以及与执行查询的成本和实际时间的比较。

EXPLAIN (ANALYSE, BUFFERS) 在分析之上使用以获取来自缓存和磁盘的行/页数以及缓存的行为方式。

EXPLAIN (ANALYSE, BUFFERS, VERBOSE) 获取有关查询的详细信息和附加信息。

EXPLAIN(ANALYSE,BUFFERS,VERBOSE,FORMAT JSON)是以特定格式导出的方式；在这种情况下，JSON。

8、执行计划查看

查询计划的元素

无论复杂性如何，任何查询计划都有一些基本结构。在本节中，将重点关注这些结构，这将有助于以抽象的方式理解查询计划。

查询的节点

查询计划由节点组成：

 

一个节点可以被认为是数据库执行的一个阶段。节点大多是嵌套的，如上图所示；在Seq Scan它之前和之上完成，然后应用该Limit子句。可以添加一个Where子句来理解多层次的嵌套。

 explain select * from test_table where code = '0002222' limit 10 offset 500;

 

l  筛选ID > 10000 的行。

l  使用过滤器进行顺序扫描。

l  在顶部应用LIMIT条件。

如您所见，数据库识别出只需要 10 行，并且一旦达到所需的 10 行就不会再进行扫描。当前，已关闭查询并行，SET max_parallel_workers_per_gather =0; ，以便计划更简单。

查询规划器中的成本

成本是数据库查询计划的关键部分，由于它们的表示方式，这些成本很容易被误解。

 

需要注意的几个重要事项是：

l  LIMIT条款的启动成本不为零。这是因为启动成本汇总到顶部，看到的是其下方节点的成本。

l  总成本是一个衡量标准，与规划者的相关性比与用户的相关性更高。

l  通常，顺序扫描在估计方面很模糊，因为数据库不知道如何优化它们。索引可以极大地加速带有WHERE子句的查询。

l  Width很重要，因为一行越宽，需要从磁盘获取的数据就越多。

如果我们实际运行查询，那么成本会更有意义。

数据库规划和执行

计划和执行时间是仅使用EXPLAIN ANALYSE选项获得的指标。

 

Planner（Planning Time）根据各种参数决定查询应该如何运行，Executor（执行时间）运行查询。上面指出的这些参数是抽象的，适用于任何类型的查询。运行时间以毫秒表示。极少的场景，会出现Plan程序可能需要更多时间来计划查询，而执行程序需要更少时间。它们不一定需要彼此匹配，但如果它们差距很多，那么就要检查其原因了。

在典型代表在线事务处理的 OLTP 系统中，任何计划和执行的总和应该小于 50 毫秒，除非它是分析查询/大量写入/已知异常。在典型的业务中，交易通常从数千到数百万不等。应始终非常仔细地观察这些执行时间，因为这些较小的成本较高的查询可能汇总起来并增加巨大的开销。

优化查询从这里出发

已经涵盖了从查询生命周期到规划器如何做出决策的步骤，本文省略了像节点类型（扫描、排序、连接）这样的主题，因为它们交为复杂，另需文档说明。本文的目的是泛泛了解查询规划器的工作原理、影响其决策的因素以及KingbaseES 提供的工具以更好地理解规划器。

 

posted @   KINGBASE研究院  阅读(352)  评论(0)  编辑  收藏  举报
编辑推荐：
· Linux系列：如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列：如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列（二）：开始使用ML.NET
阅读排行：
· 被坑几百块钱后，我竟然真的恢复了删除的微信聊天记录！
· 没有Manus邀请码？试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单，K8s 太复杂？w7panel 让容器管理更轻松！
点击右上角即可分享
微信分享提示