金仓数据库KingbaseES 绑定变量窥探机制

最新推荐文章于 2023-12-12 18:43:23 发布

沉舟侧畔千帆过_

最新推荐文章于 2023-12-12 18:43:23 发布

阅读量494

点赞数

分类专栏：数据库文章标签：数据库 oracle sql 金仓数据库 kingbase

本文链接：https://blog.csdn.net/arthemis_14/article/details/128135419

版权

数据库专栏收录该内容

550 篇文章 29 订阅

订阅专栏

对于数据严重倾斜的，极端如以下例子，不同的传入值，可能执行计划不同，制定执行计划时，就要求知道变量的值。

对于绑定变量的情况，我们知道Oracle 有optim_peek_user_binds 参数，控制是否启用变量窥探。KingbaseES 也有类似参数，控制是否启用变量窥探。

窥探机制

KingbaseES 采用以下判断机制，决定是否固定执行计划：

前5次执行时，每次都会根据实际传入的实际绑定变量新生成执行计划进行执行，即每次都是硬解析，同时会记录这5次的执行计划；
当第6次开始执行时，会生成一个通用的执行计划（generic plan），同时与前5次的执行计划进行比较，如果比较的结果是通用执行计划不比前5次的执行计划差，以后就会把这个通用的执行计划固定下来，这之后即使传入的值发生变化后，执行计划也不再变化。这就相当于Oracle打开了绑定变量窥视的功能。
当然，当第6次开始执行时，如果通用的执行计划（generic plan）比前5次的某一个执行计划差，则以后则每次都重新生成执行计划，即以后永远都是硬解析了。

构建例子

1、构建测试数据

create table t1(id integer,name text);
insert into t1 select 1,repeat('a',100) from generate_series(1,1000000);
insert into t1 select 2,repeat('b',100) ;
create index ind_t1_id on t1(id);
analyze t1;
prepare t1_plan(integer) AS select count(*) from t1 where id=$1;

2、测试窥探机制

测试一：

test=# prepare t1_plan(integer) AS select * from t1 where id=$1;
PREPARE
test=#
test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = $1)
(2 rows)

test=# explain execute t1_plan(2);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = $1)
(2 rows)

test=# explain execute t1_plan(2);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = $1)
(2 rows)

结论：可以看到，第6次执行时，变为 id=$1，说明执行计划变成通用执行计划了。后续，即使传入的值是 2，也不会走索引。

测试二：

test=# prepare t1_plan(integer) AS select * from t1 where id=$1;
PREPARE
test=# explain execute t1_plan(2);
                              QUERY PLAN
----------------------------------------------------------------------
 Index Scan using ind_t1_id on t1  (cost=0.42..4.44 rows=1 width=105)
   Index Cond: (id = 2)
(2 rows)

test=# explain execute t1_plan(2);
                              QUERY PLAN
----------------------------------------------------------------------
 Index Scan using ind_t1_id on t1  (cost=0.42..4.44 rows=1 width=105)
   Index Cond: (id = 2)
(2 rows)

test=# explain execute t1_plan(2);
                              QUERY PLAN
----------------------------------------------------------------------
 Index Scan using ind_t1_id on t1  (cost=0.42..4.44 rows=1 width=105)
   Index Cond: (id = 2)
(2 rows)

test=# explain execute t1_plan(2);
                              QUERY PLAN
----------------------------------------------------------------------
 Index Scan using ind_t1_id on t1  (cost=0.42..4.44 rows=1 width=105)
   Index Cond: (id = 2)
(2 rows)

test=# explain execute t1_plan(2);
                              QUERY PLAN
----------------------------------------------------------------------
 Index Scan using ind_t1_id on t1  (cost=0.42..4.44 rows=1 width=105)
   Index Cond: (id = 2)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

test=# explain execute t1_plan(1);
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..29742.01 rows=1000001 width=105)
   Filter: (id = 1)
(2 rows)

结论：如果第6次与前5次执行计划是不一致的，后续都不会走通用的执行计划。本例中，哪怕后续连续超过 5次传入同一值，都不会固定执行计划。

3、窥探机制问题

与Oracle 相比，KES需要前 5 次执行绑定变量的SQL，都会窥探变量值，只有在执行计划都一致时，第6次执行时才会固定执行计划。

可以看到，这种机制相比于Oracle，出现执行计划错误的概率更低，但是还是有一定的几率。

为了解决该问题，KingbaseES提供参数，可以关闭变量窥探机制。

plan_cache_mode 参数控制是否固定执行计划（执行计划共享），还是永远进行硬解析。可以取以下三个值：

auto: 默认值，即根据以上的机制选择是否固定执行计划。
force_custom_plan: 关闭绑定变量窥视，永远进行硬解析。
force_generic_plan: 走通用的固定执行计划（generic plan）。比如：是否走索引是根据distinct 值的数量，而不是第一个传入的变量值。

注意：与Oracle 实例级的执行计划共享不同，KingbaseES 只支持会话级执行计划共享。

沉舟侧畔千帆过_

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
金仓数据库KingbaseES 绑定变量窥探机制

对于数据严重倾斜的，极端如以下例子，不同的传入值，可能执行计划不同，制定执行计划时，就要求知道变量的值。对于绑定变量的情况，我们知道Oracle 有optim_peek_user_binds 参数，控制是否启用变量窥探。KingbaseES 也有类似参数，控制是否启用变量窥探。
复制链接

扫一扫