共计 2187 个字符，预计需要花费 6 分钟才能阅读完成。
SQL 引擎作为数据库系统的三大外围模块之一，有着承前启后的作用。SQL 引擎负责承接客户端输出的 SQL 申请，并依据负载场景将 SQL 语句通过其解析、优化、执行等模块的解决后，将后果返回至客户端。
这看似简略的运行过程却波及 SQL 引擎各模块的作用和工作原理。 9 月 1 日 19:30 内核实战教程第四期 将会带你走进数据库 SQL 引擎，理解 SQL 引擎的各个知识点。同时，带你理解 OceanBase 在查问改写和查问优化方面的实际和教训。家喻户晓，查问改写模块是优化器的重点和难点，也是 SQL 性能调优工作者和 DBA 都须要把握的基础知识，通过本期教程，你会学习大量的改写规定，把握改写和优化的精华，设计出更高效的 SQL。
此外，本期教程还有 OceanBase 技术专家带你在线解析 MiniOB select-meta 实现思路，手把手教你实战数据库内核。
本期能帮你解决什么问题？
1、「查问改写」 模块如何改写 SQL，能力对内核而言是一条“好 SQL”？
2、通过编写 SQL 语句能够晋升执行性能，为什么还须要查问优化器来对 SQL 进行优化？
直播内容抢“鲜”知
查问改写
为什么要改写 SQL 呢？
咱们晓得，查问改写模块向来是查问优化器的重点和难点，因为 SQL 是一种描述性的语言，所以为了获取同一个查问后果，不同用户会写出不同的 SQL。查问改写的目标就是把“用户的好 SQL”转化为更加易于优化的 SQL。
而在查问改写的过程中，通常会面临两个挑战。
第一个挑战是正确性，正确性其实是很重要的一项指标，如果改写的 SQL 不等价，意味着返回后果可能不正确。在 OceanBase 里，工作人员每次做改写规定时，必须确定其语义上是等价的，有时须要从关系代数的角度证实改写规定是正确的，或通过大量的测试场景来保障正确性。
第二个挑战是齐备性，也就是说设计的改写规定，必须足够通用，可能笼罩用户所有可能的写法。
查问改写对完整性体现在模式匹配方面，正确性体现在等价变动方面。除此之外查问改写还要留神有效性的判断。
在 OceanBase 数据库中，所有的查问改写能够分为两类。一类是基于规定的改写，总是把 SQL 往好的方向改写。其次要特点是触发这类改写总能生成更好的执行打算，这类改写算法总是无效的。
第二类是基于代价的改写，其次要特点是某些场景下改写后能生成更好的执行打算，有些场景下则不能。是否能够触发这类改写，须要优化器评估改写前和改写后 SQL 打算的代价，并依据改写是否能够升高打算代价决定改写是否触发。
在理论执行过程中，OceanBase 的查问改写框架会依照预约义的程序，一直迭代基于规定的改写和基于代价的改写，直到收敛。
目前 OceanBase 的改写模块实现了十分多的改写规定，既蕴含学术届和工业界常见的改写规定，也蕴含了优化器开发人员从业务的理论场景中提炼出的改写规定。例如，基于规定的常量折叠、SPJ 和非 SPJ 的视图合并、连贯打消等，基于代价的 Or-expansion、Group by replacement、窗口函数改写等。
查问优化
OceanBase 的物理优化器次要蕴含打算枚举和代价计算两局部。打算枚举能够枚举蕴含 Deep Tree、Bushy Tree 在内的多种打算形态，并且蕴含了 DP、Linear 在内的两种枚举算法。代价计算则波及到统计信息、选择率计算和两头后果预计，以及代价模型等多方面因素的影响。
打算枚举是一个有确定性的算法。如果有三种连贯形式，就会呈现六个执行打算。每个执行打算都会计算代价，最终抉择代价最小的执行打算。
在星型查问下，如果连贯表超过 25 张，在不思考物理算子实现、不思考基于代价的改写、不思考分布式优化的状况下，其逻辑执行打算就曾经到了 2 亿级别。因而如何高效的枚举执行打算是查问优化面临的一个重要挑战。
在 OceanBase 里，如果基表个数小于十张，会应用动静布局算法。首先，枚举所有一张表的执行打算；而后，枚举两张表的执行打算；接着，枚举三张表的执行打算，以此类推。如果超过十张基表，在开源版本会有启发式的算法，疾速收敛执行打算。
当 OceanBase 在枚举执行打算时，除了要保留代价最小的执行打算，还要保留存在 interesting order 的打算。因为存在 interesting order 的打算的序可能会被后续的算子用于打消排序。
索引 (a) 的执行工夫是十秒；索引(b) 的执行工夫也是十秒；主表的执行打算工夫是五秒。此时，因为主表代价是最小的，p1 是有序索引，故保留 p1 和 p3。
当连贯程序生成实现后，优化器会顺次调配其它的算子，例如 group by、窗口函数、order by 等。在调配其它算子的过程中仍然遵循保留代价最小的打算和存在 interesting order 的打算的准则，直到所有算子调配实现后讲代价最低的打算作为最终的执行打算。
更多具体内容，敬请关注 9 月 1 日 19:30「从 0 到 1 数据库内核实战教程」官网课程。
附录：
内核实战教程第一期 | 成为内核开发者的第一步：搭建研发环境
内核实战教程第二期|带你揭开数据库存储构造的神秘面纱
内核实战教程第三期|为什么索引能够让查问变快？
课程回放
赶快扫描下方二维码进入「OceanBase 入门到实战」群
关注课程动静，和更多小伙伴一起学习提高
为帮忙大家更好地学习数据库常识，结交新的敌人
将来 OceanBase Meetup 也会走到更多的城市中
大家进群后批改本人的群昵称哦【格局：姓名 - 城市 - 职位】
