parsetree

这篇笔记主要记录mysql的基础架构，一条查询语句是如何执行的。 比如，在我们从student表中查询一个id=2的信息： select * from student where id = 2; 在解释这条语句执行流程之前，我们看看MySQL的基础架构。 MySQL的逻辑架构 Server层包括连接器、查询缓存、分析器、优化器、执行器 ，涵盖 MySQL 的大多数核心服务功能，以及所有的 内置函数 ，所有 跨存储引擎的功能 都在这一层实现，比如存储过程、触发器、视图等。 存储引擎层负责数据的存储和提取 。其架构模式是插件式的，支持InnoDB、MyISAM、Memory 等多个存储引擎，MySQL默认的存储引擎是InnoDB。 1, 连接器 我们在使用数据库之前，需要连接到数据库，连接语句是 mysql -h $ip -u $username -p $password 而我们的连接器就是处理这个过程的，连接器的主要功能是 负责跟客户端建立连接、获取权限、维持和管理连接 ，连接器在使用的过程中如果该用户的权限改变，是不会马上生效的，因为用户权限是在连接的时候读取的，只能重新连接才可以更新权限 连接器与客户端通信的协议是 tcp 协议的，连接以后可以使用 show processlist; 看到执行的连接数 MySQL [abc]> show processlist; +------+

摘要 ：以一定的算法结合解析树中的各结点，计算出来一个整数值，用来唯一标识这一类SQL，这个整数值被称为Unique SQL ID，Unique SQL ID相同的SQL语句属于同一个“Unique SQL”。 1、 什么是Unique SQL 用户执行SQL语句时，每一个SQL语句文本都会进入解析器（Parser），生成“解析树”（parse tree）。遍历解析树中各个结点，忽略其中的常数值，以一定的算法结合树中的各结点，计算出来一个整数值，用来唯一标识这一类SQL，这个整数值被称为Unique SQL ID，Unique SQL ID相同的SQL语句属于同一个“Unique SQL”。 例如，用户先后输入如下两条SQL语句： select * from t1 where id = 1; select * from t1 where id = 2; 这两条SQL语句除了过滤条件的常数值不同，其他地方都相同，由此生成的解析树的拓扑结构完全相同，故Unique SQL ID也相同。因此两条语句属于如下同一个Unique SQL： select * from t1 where id = ?; GaussDB内核会对所有上面形式的SQL语句汇总统计信息，通过视图呈现给用户。通过这种方式，可以排除一些无关的常量值的干扰，获得某一类SQL语句的统计数据，为性能分析和问题定位提供数值依据。

9.5的常用的一些设置，自己mark一下防止丢失;参数用途的说明，不做说明，仅为自己记录 <pre> max_connections = 3000 work_mem = 8MB shared_buffers = 1GB fsync = off synchronous_commit = off commit_delay = 500 commit_siblings = 25 checkpoint_completion_target = 0.9 autovacuum = on bgwriter_delay=10ms full_page_writes=off wal_writer_delay=10ms max_wal_size=32GB hot_standby=on wal_receiver_status_interval=1s hot_standby_feedback=on random_page_cost=1.0 maintenance_work_mem=64MB autovacuum_work_mem=64MB archive_mode=off enable_nestloop=off </pre> 9.6的并行查询参数,黑体标明， 官方说明： <pre> <b>Parallel query execution is not (yet) enabled by default. To

UI： 用于提交查询的客户端，hive自带有CLI(command line)，现在推荐使用beeline DRIVER： 1.用于接收客户端提交的SQL，并实现了session控制 2.并提供了jdbc/odbc的fetch和execute功能 COMPILER： 编译器，负责解析SQL，并从METASTORE那里获取元数据生成执行计划，然后发给DRIVER 执行计划就是一个DAG(有向无环图) 组件： 1.Parser：将查询语句转变成一个parse tree 2.Semantic Analyser：将parse tree变成一个内部的查询表示(依然是基于查询块，而不是operator tree)。同时在这一步也会做语法检查，类型检查和类型隐式转换 3.Logical Plan Generator：将内部的查询表示转变成一个逻辑计划(包含一个operator tree)，一些operator是关系代数的filter，join等，另一些是hive特定的，用于将逻辑计划变成一系列的map/reduce job,比如reduceSink operator(出现在map-reduce边界)；这一步Optimizer也会对查询进行优化,比如map端聚合等 4.Query Plan Genertor：将逻辑计划转换成一系列的map-reduce tasks.做法是，通过对operator

在上一篇博文中，我介绍了LOGO语言的C#实现，在该项目中，我使用了.NET下的语法解析框架：Irony。Irony框架最开始的时候是由Roman Ivantsov发布在codeplex上的一个开源项目，它使用MIT协议开源。由于2017年的时候，微软关闭了codeplex服务，为了让这个优秀的项目能够继续为人所用，我将其复制到了我的Github账号下，并将其移植到NET Standard 2.0，地址是： https://github.com/daxnet/irony 。于是，Irony目前可以在.NET Core下使用了。事实上，Github中有很多Irony的版本，但大多数都不支持.NET Core。 不仅如此，我还在Azure DevOps上配置了持续集成，因此，你可以通过NuGet很方便地使用Irony。Irony相关的NuGet包有两个，你需要在你的项目中同时安装以下两个NuGet包： Install-Package Irony.NetCore -Version 1.1.11 Install-Package Irony.Interpreter.NetCore -Version 1.1.11 接下来，我介绍一下如何用Irony实现一个语法解析器，我们以SQL语句为例进行介绍。 定义语法 所有使用Irony框架的语法定义，都必须继承于Grammar类