大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说openGauss SQL引擎 （上）「建议收藏」,希望您对编程的造诣更进一步.
数据库的SQL引擎是数据库重要的子系统之一，它对上负责承接应用程序发送的SQL语句，对下负责指挥执行器运行执行计划。其中优化器作为SQL引擎中最重要、最复杂的模块，被称为数据库的“大脑”，优化器产生的执行计划的优劣直接决定数据库的性能。
本文从SQL语句开始介绍，对SQL引擎的各个模块进行全面的说明。
一、 SQL引擎概览
SQL引擎是数据库系统的重要组成部分，主要职责是将应用程序输入的SQL语句在当前负载场景下生成高效的执行计划，在SQL语句的高效执行上扮演重要角色。
SQL语句在SQL引擎中的执行过程如下图所示。
图 SQL语句在SQL引擎中的执行流程
从上图中可以看出，应用程序的SQL语句需要经过SQL解析生成逻辑执行计划、经过查询优化生成物理执行计划，然后将物理执行计划转交给查询执行引擎做物理算子的执行操作。
SQL解析通常包含词法分析、语法分析、语义分析几个子模块。SQL是介于关系演算和关系代数之间的一种描述性语言，它吸取了关系代数中一部分逻辑算子的描述，而放弃了关系代数中“过程化”的部分，SQL解析主要的作用就是将一个SQL语句编译成为一个由关系算子组成的逻辑执行计划。
描述语言的特点是规定了需要获取的 WHAT，而不关心 HOW，也就是只关注结果而不关注过程，因此SQL描述性的特点导致查询优化在数据库管理系统中具有非常重要的作用。
查询重写则是在逻辑执行计划的基础上进行等价的关系代数变换，这种优化也可以称为代数优化，虽然两个关系代数式获得的结果完全相同，但是它们的执行代价却可能有很大的差异，这就构成了查询重写优化的基础。
在早期的数据库管理系统中，通常采用基于启发式规则的方法来生成最优的物理执行计划，但是这种基于规则的优化的灵活度不够，常常产生一些次优的执行计划，而代价估算的引入，则从根本上解决了基于规则优化的不足。
基于代价的优化器一方面生成“候选”的物理执行路径，另一方面计算这些执行路径执行代价，这样就建立了执行路径的筛选标准，从而能够通过比较代价而获得最优的物理执行计划。
二、 SQL解析
SQL语句在数据库管理系统中的编译过程符合编译器实现的常规过程，需要进行词法分析、语法分析和语义分析。
- 词法分析:从查询语句中识别出系统支持的关键字、标识符、运算符、终结符等，确定每个词固有的词性。
- 语法分析:根据SQL的标准定义语法规则，使用词法分析中产生的词去匹配语法规则，如果一个 SQL 语句能够匹配一个语法规则，则生成对应的抽象语法树（Abstract Syntax Tree，AST）。
- 语义分析:对语法树进行有效性检查，检查语法树中对应的表、列、函数、表达式是否有对应的元数据，将抽象语法树转换为逻辑执行计划(关系代数表达式)。 在SQL标准中，确定了SQL的关键字以及语法规则信息，SQL 解析器在做词法分析的过程中会将一个SQL语句根据关键字信息以及间隔信息划分为独立的原子单 位，每个单位以一个词的方式展现，例如有SQL语句:
SELECT w_name FROM warehouse WHERE w_no = 1;
该SQL语句可以划分的关键字、标识符、运算符、常量等原子单位如表1所示。
<center>表 词法分析的特征</center>
| 词性 | 内容 |
|---|---|
| 关键字 | SELECT、FROM、WHERE |
| 标识符 | w_name、warehouse、w_no |
| 操作符 | = |
| 常量 | 1 |
语法分析会根据词法分析获得的词来匹配语法规则，最终生成一个抽象语法树， 每个词作为语法树的叶子节点出现，如下图所示。
图 抽象语法树
抽象语法树表达的语义还仅仅限制在能够保证应用的SQL语句符合SQL标准的规范，但是对于SQL语句的内在含义还需要做有效性检查。
- 检查关系的使用:FROM 子句中出现的关系必须是该查询对应模式中的关系或视图。
- 检查与解析属性的使用:在SELECT语句中或者WHERE子句中出现的各个属性必须是FROM子句中某个关系或视图的属性。
- 检查数据类型:所有属性的数据类型必须是匹配的。在有效性检查的同时，语义分析的过程还是有效性语义绑定(Bind)的过程，通过语义分析的检查，抽象语法树就转换成一个逻辑执行计划。逻辑执行计划可以通过关系代数表达式的形式来表现，如下图所示。
图 关系代数表达式
三、查询优化
SQL语句在编写的过程中，数据库应用开发人员通常会考虑以不同的形式编写SQL语句达到提升执行性能的目的。那么，为什么还需要查询优化器来对 SQL进行优化呢? 这是因为一个应用程序可能会涉及大量的SQL语句，而且有些 SQL语句的逻辑极为复杂，数据库开发人员很难面面俱到地写出高性能语句，而查询优化器则具有一些独特的优势：
- 查询优化器和数据库开发人员之间存在信息不对称。查询优化器在优化的过程中会参考数据库统计模块自动产生的统计信息，这些统计信息从各个角度来描述数据的分布情况，查询优化器会综合考虑统计信息中的各种数据，从而得到一个比较好的执行方案，而数据库开发人员一方面无法全面地了解数据的分布情况，另一方面也很难通过统计信息构建一个精确的代价模型对执行计划进行筛选。
- 查询优化器和数据库开发人员之间的时效性不同。数据库中的数据瞬息万变，一个在 A 时间点执行性能很高的执行计划，在B时间点由于数据内容发生了变化，它的性能可能就很低，查询优化器则随时都能根据数据的变化调整执行计划，而数据库应用程序开发人员则只能手动地调整SQL语句，和查询优化器相比，它的时效性比较低。
- 查询优化器和数据库开发人员的计算能力不同。目前计算机的计算能力已经大幅提高，在执行数值计算方面和人脑相比具有巨大的优势，查询优化器对一个 SQL语句进行优化时，可以从成百上千个执行方案中选择一个最优方案，而人脑要计算这几百种方案需要的时间要远远长于计算机。
因此，查询优化器是提升查询效率的非常重要的一个手段，虽然一些数据库也提供了人工干预执行计划生成的方法，但是通常而言，查询优化器的优化过程对数据库开发人员是透明的，它自动进行逻辑上的等价变换、自动进行物理执行计划的筛选，极大地提高了数据库应用程序开发人员的“生产力”。
依据优化方法的不同，优化器的优化技术可以分为：
- RBO(Rule Based Optimization，基于规则的查询优化):根据预定义的启发式规则对SQL语句进行优化。
- CBO(CostBasedOptimization，基于代价的查询优化):对SQL语句对应的待选执行路径进行代价估算，从待选路径中选择代价最低的执行路径作为最终的执行计划。
- ABO(AI Based Optimization，基于机器学习的查询优化):收集执行计划的特征信息，借助机器学习模型获得经验信息，进而对执行计划进行调优，获得最优的执行计划。
在早期的数据库中，查询优化器通常采用启发式规则进行优化，这种优化方式不够灵活，往往难以获得最优的执行代价，而基于代价的优化则能够针对大多数场景高效筛选出性能较好的执行计划，但面对千人千面的用户和日趋复杂的实际查询场景，普适性的查询优化难以捕捉到用户特定的查询需求、数据分布、硬件性能等特征，难以全方位满足实际的优化需求。
近年来 AI技术发展迅速，特别是在深度学习领域。ABO 在建模效率、估算准确率和自适应性等方面都有很大优势，有望打破 RBO 和 CBO 基于静态模型的限制。通过对历史经验的不断学习，ABO 将目标场景的模式进行抽象化，形成动态的模型，自适应地针对用户的实际场景进行优化。openGauss采用基于 CBO 的优化技术，另外在ABO方面也在进行积极探索。
查询优化的详细内容将在下一篇内容进行介绍。
Gauss松鼠会是汇集数据库爱好者和关注者的大本营，大家共同学习、探索、分享数据库前沿知识和技术，互助解决问题，共建数据库技术交流圈。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/6265.html
