SQL查询优化器浅析|青训营笔记

这是我参与【第四届青训营】笔记创造活动的第一天。  1.SOL查询优化器处理流程  SOL是一种声明式语言，用户只描述做什么，没有告诉数据库做什么 目标：找到一个正确且执行代价最小的物理执行计划
查询优化器是数据库的大脑，在大数据场景下对查询性能至关重要，按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段。 一般SOL越复杂，Join的表越多，数据量越大，查询优化的意义就越大，不同执行方法的性能差别可能有成百上千倍。 SOL->Parser->AST->Analyzer->Logical Plan->Optimizer->physical->Executor ✓Parser 把文本变成抽象语法树结构（AST） 词法分析阶段:拆分字符串，提取关键字，字符串，数值等 语法分析阶段:把词条按照定义的语法规则组装成抽象语法树结构 实现：递归下降（ClickHouse,Flex和Bison(PostgreSQL),JavaCC(Flink),Antlr(Presto,Spark) ✓Analyzer 访问库/表元信息并绑定 判断 SQL 是否合理，比如数据库，表和列名是否存在，列的数据类型是否正确 将 AST 转换成逻辑计划树（在某些系统中这个工作由一个 Converter 完成） ✓Logical Plan 逻辑地描述SOL对应的分步骤计算操作 计算操作：算子 ✓Plan Fragment : 执行计划子树 目标：最小化网络数据传输 利用数据的物理分布 增加Shuffle算子 ✓Executor 单机运行：cache,pipeline,SIMD 多机运行：一个fragment对应多个实例  2.常见的查询优化器 ： 主流的查询优化器都包含CBO和RBO Apache Calcite是大数据领域很流行的查询优化器 Top-down Optimizer：从目标输出开始，由下往上遍历，找出完整的最有执行计划，如Volcano/Cascade,SOLServer Bottom-up Optimizer：从零开始，由下往上遍历计划数，找出完整的执行计划，如System R,PostgreSQL,IBM DB2  Rule-based Optimizer(RBO) ： 根据关系代数等等价语义，基于启发式规则，重写查询，会访问的表的圆信息(catalog),不会涉及具体的表数据。主流RBO实现一般都有几百条基于经验归纳得到的优化规则 优点：实现简单 缺点：无法解决多表连接问题，无法确定和选择最优的分布式 Join/Aggregate 执行方式  Cost-based Optimizer(CBO) ： 使用代价模型和统计信息估算执行计划的代价，通常使用贪心算法或者动态规划选择代价最小的执行计划。大数据背景下CBO对查询性能非常重要

为什么SQL会如此流行？ 有 MySQL、Oracle 之类使用 SQL 作为交互语言的数据库 有 JDBC、ODBC 之类和各种数据库交互的标准接口 有大量数据科学家和数据分析师等不太会编程语言但又要使用数据的人 多个大数据计算引擎都支持 SQL 作为更高抽象层次的计算入口

SQL 相关的前沿趋势？ 存储计算分离 HSAP, HTAP, HTSAP Cloud Native, Serverless 数据仓库，数据湖，湖仓一体，联邦查询 智能化：AI4DB，DB4AI