概述：了解KingbaseES查询计划对于开发人员和数据库管理员来说都是一项关键技能。这可能是优化SQL查询的第一件事，也是验证优化的SQL查询是否确实实现期望结果的方式。1、Ki
概述：了解KingbaseES查询计划对于开发人员和数据库管理员来说都是一项关键技能。这可能是优化SQL查询的第一件事，也是验证优化的SQL查询是否确实实现期望结果的方式。
1、KingbaseES数据库中的查询生命周期
每个查询都会经历不同的阶段，了解下面周期的每个阶段，对理解数据库是很重要的。
第一阶段是通过JDBC/ODBC或通过其他方式如KSQL（客户端工具）连接到数据库。
第二阶段是将查询转换为解析树的格式，就像 SQL 查询的编译形式。
第三阶段是重写系统/规则系统。它采用从第二阶段生成的解析树，并以规划器/优化器可以开始在其中工作的方式重写它。
第四阶段是最重要数据库的核心。规划器使得知执行器知道如何执行查询、使用什么索引、是否扫描较小的表以消除更多不必要的记录等问题。
第五个也是最后一个阶段是执行器，它执行实际执行并返回结果。
下面将描述第四阶段的工作内容。
2、数据设置
首先建立一些表来运行本文的实验。
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;
test=# explain select * from test_table limit 10;
QUERY PLAN
--------------------------------------------------------------------------
Limit (cost=0.00..0.22 rows=10 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 提供的工具以更好地理解规划器。
KingbaseES 查询计划剖析的相关教程结束。
京公网安备 11010802041100号