前言
几周之前在Meetup中说到昆仑分布式数据库的架构的一些特点，因而，有敌人好奇昆仑分布式数据库计算节点如何反对读写存储节点中的变量。
本篇文章就来论述阐明下
性能具体介绍
- 使set [shard] global/session/local/PERSIST/PERSIST_only VARNAME=VALUE
的语法失效；总是假如VARNAME是MySQL的；计算节点会发送SET语句给所有的存储节点去执行，且在一个session的生命期当中，所有设置过的session 变量的值会在计算节点的session外面缓存。
在切换存储集群主节点后，新的主节点会应用缓存的session变量值设置给新的存储集群主节点，确保统一的会话（连贯）状态。
set session innodb_lock_wait_timeout = 3;设置全局变量：
set global innodb_lock_wait_timeout = 4; set persist_only innodb_lock_wait_timeout = 11;2.set VARNAME=VALUE 语句，在PostgreSQL客户端连贯的时候会默认以PostgreSQL的变量名来对待他们，如果变量名不存在，则会把他们看成是MySQL的session变量。在客户端MySQL连贯时，会默认把他们视为MySQL的session变量，如果变量名不存在则把他们视为PostgreSQL变量。set innodb_lock_wait_timeout = 2;
- 计算节点会缓存MySQL配对的session var-value，且如果shard连贯被从新设置或者从新连贯，计算节点会把缓存的变量发送给MySQL节点。
- 也反对set @@global/session/local/persist/persist_only.varname=value
语句，且总是假设为MySQL变量，因为只有MySQL有这样的SET语法。但因shift/reduce抵触而不反对set @@VARNAME=VALUE。
set @@global.innodb_lock_wait_timeout = 4;set @@innodb_lock_wait_timeout = 2;
(不反对该语法)
- 反对show [session/local/global] variables like 'wildcard-filter语法且总是假设是MySQL变量，因为MySQL才有这样的语法，PostgreSQL没有。对于show varname语法总是先假设是PostgreSQL变量。如果变量名不是PostgreSQL变量，则被假设是MySQL变量。
show global variables like 'innodb_lock_wait_timeout'；show session variables like 'innodb_lock_wait_timeout';show local variables like 'innodb_lock_wait_timeout';- 反对在Kunlun计算节点外面的选项show [session/global/local] variables like里抉择 STRICT来展现只有计算节点容许拜访的MySQL变量。
show local variables like 'innodb_lock_wait_timeout' strict;show session variables like 'innodb_lock_wait_timeout' strict;show global variables like 'innodb_lock_wait_timeout' strict;- 当执行show语句时会获得一个变量的值，间接发送给任意存储shard来获取他的值。
总结
昆仑分布式数据库的计算节点反对读写存储节点的零碎变量，能够给用户带来很大的便当。
例如，用户能够在计算节点的连贯中执行一个set global var=value;语句，来设置所有后端集群的var变量的值为value。也能够通过在计算节点执行一个set session var=value;就把以后会话（连贯）中的var变量的值设置为value。
这部分性能的对应测试脚本从https://gitee.com/zettadb/kun... 下面拉下来，在src/test/regression/sql/vars.sql 中，这些测例也展现了MyQL变量拜访的性能。
*KunlunDB我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
END