手写toadb又更新了

[数据库小工]

## updated by 2023/11/15

### 概述

主要更新了解析树，增加了查询树和执行计划树的生成，这有利于带条件SQL和复杂SQL处理，同时节点化各个关系代数运算后，有利于执行计划优化的实现。与此同时，更新了执行器，可以通过输入的计划树来执行，不再像以前通过SQL解析结果。

 

### 更新内容

下面将分别描述更新的内容：

* 解析树

> 在词法分析、语法分析的过程中，会生成解析树，将用不同节点来表示各子句及存储它们传递的信息，这样有助于后续步骤的开展。在开发解析树时，尽可能与存储模型，数据库类型无关，希望做成一个通用的SQL解析器，它的输入就是SQL字符，输出就是解析树，不像现在每种类型的数据都有一个解析器。真正与数据库，存储模型相关的，是在下一步骤，也就是查询树。

 

* 查询树

> 查询树，也叫做逻辑执行计划，它的主要是把SQL用关系代数进行表达，不同关系代数用不同节点表示，树的层次来表示节点之间的关系。当然在转换的过程中，会对SQL中的数据进行检查，比如表是否存在，表的元数据是否一致等；同时还会对一些SQL子句进行展开和替换，比如对`sellect *`, 将它的结果目标列替换为所有的属性列，这就是常说的重写的过程。当然，在真实数据库中，重写阶段还会对视图，规则等进行处理。

 

* 计划树

> 计划树，也叫执行计划，或者叫做物理执行计划树，它是一个树状结构，每个节点的类型对应着真正要执行的动作。当然未来会在生成计划树之前，可以再增加一个优化器，对各种可能的SQL子句进行重新整理，提升子句，逻辑检查等，这将大大提升执行的效率。

 

* 执行器

> 之前只对简单的SQL执行全表查询，更新后通过输入的物理执行计划，只需要递归的遍历执行计划的节点，按对应节点的类型执行相应动作即可，然后返回target对应的元组，更新后执行器更加通用，更加灵活。

> 未来增加索引，优化节点执行动作，增加节点执行接口，这些将变成局部修改。

 

* 内存管理

> 之前对于动态内存申请并没有进行释放管理，本次增加了一个简单的内存管理，实现一种内存上下文的机制，在上下文使用完成后，会统一释放之前上下文中申请的内存。在程序退出时，会释放所有申请的内存。同时，为了方便调式，对于动态申请的内存，标定了内存的起始和结尾，这样可以方便探测到内存越界的情况。

> 这是一个公共组件，目前只是简单实现，后期与数据库的缓存管理一起进行模块级实现。

 

### 举例说明

下面举几个例子说明一下变化情况。

* insert 语句

 

> 比如`insert into tablename(...) values(...),(...);` ,这条插入语句。

 

> 之前是通过遍历values子句，循环执行执行表的动作。

 

> 更新之后，values子句转换为一个虚似的表，在执行计划中，会有一个表扫描的节点，将返回的元组，再执行一个ModifyTable动作。这样就是一个通用的操作，未来很方便的支持`insert into ... select ...`这种形式，或者更复杂的形式。

 

* select 语句

如上所述，之前只有一个表的全表扫描。现在对于表扫描，实现一种迭代器的扫描方式，每次可以返回下一个扫描到的元组。对于多表和带条件表达式时，增加控制节点，比如两个表的连接，会增加嵌套循环节点，先从外表中拿到一个元组，再从内表中依次扫描元组，如果两表都有元组，则输出结果，当内表遍历完时，从外表再扫描下一个元组，再从头遍历内表。

 

目前只有顺序扫描和嵌套循环两种实现路径。

 

### 支持情况

 

目前toadb支持的SQL语法有：

* DDL

> `create table tableName(columnName type,...);`

> `drop table tableName;`

创建表和删除表的SQL支持；

 

* DML

> `insert into tablename(...) values(...),(...);`

向表中插入数据，可以是一个values，也可以带多组值；

 

* DQL

> `select columName,.. from tableName,.. where qual and qual or qual;`

可以查询单个或多个表，带有条件(目前需要带一个条件)，目前对条件并没有处理，只是简单的返回全表。当查询为多表时，会以积的形式返回结果，也就是两边非空的所有列。

 

[数据库小工]

持续更新中