查询优化器

这是我参与「第四届青训营」笔记创作活动的的第2天

今天还是对于周老师讲的SQL Optimizer 解析分享一下自己的笔记，因为当时的确

这边就先来解释一下什么是查询优化

首先我们需要理解，就是说为什么叫查询优化，就是因为SQL它是一种声明式语言，就是说，我们用户值告诉你说，我们需要查什么数据，会对这些数据做什么处理，但是它没有告诉那个数据库，是怎么做的，那么这样就给了数据库很大的一个自由度，它没有规定，完成这一样一个操作，需要使用怎么样的方法，同样的事情，我们可以选择不同的方法。所以这边就有优化的空间了，所以我们就叫他查询优化

查询优化的目标

找到一个正确，就是你这个首先必须是要正确，然后运行时，我们也希望它的运行时间最快，也就是说找到执行代价最小的物理执行计划。

查询优化器就是数据库的大脑，就是你想你的查询跑的快，那查询优化是必不可少的，同时查询优化器也是数据库里面最复杂的模块，大家不用被最复杂吓到，不论在怎么复杂的东西，其实都是有规律的

查询优化器为什么复杂

最主要的原因是因为它需要考虑SQL里面的各种语法，各种边界的case，并且里面有一些问题是np的，就是说，没办法很好的去求得一个最优解。类似于mysql,是单机的，可能对于查询优化的依赖不是很重，但是在大数据场景的话，这个数据依还是很重的，因为大数据场景的话，他的SQL很复杂，多的话，可能会有几千行的SQL，并且里面会有大量的连接，数据量会很大，不论有没有查询优化，一个不同的执行方式，其中性能的差别可能会有成千上百倍，这也就是查询优化存在的意义
在查询优化之后，就到了一个物理执行计划和SQL的过程。\

查询优化器去做优化的时候，他需要去感知数据分布，充分利用上数据的亲和性，并且按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段

查询优化器分类

查询优化器分为两类：基于规则的优化器(Rule-Based Optimizer，RBO) 和基于代价的优化器(Cost-Based Optimizer，CBO) ：

基于规则的优化器(Rule-Based Optimizer，RBO)
根据优化规则对关系表达式进行转换，这里的转换是说一个关系表达式经过优化规则后会变成另外一个关系表达式，同时原有表达式会被裁剪掉，经过一系列转换后生成最终的执行计划。
RBO中包含了一套有着严格顺序的优化规则，同样一条SQL，无论读取的表中数据是怎么样的，最后生成的执行计划都是一样的。同时，在RBO中SQL写法的不同很有可能影响最终的执行计划，从而影响脚本性能。

基于代价的优化器(Cost-Based Optimizer，CBO)
根据优化规则对关系表达式进行转换，这里的转换是说一个关系表达式经过优化规则后会生成另外一个关系表达式，同时原有表达式也会保留，经过一系列转换后会生成多个执行计划，然后CBO会根据统计信息和代价模型(Cost Model)计算每个执行计划的Cost，从中挑选Cost最小的执行计划。由上可知，CBO中有两个依赖：统计信息和代价模型。统计信息的准确与否、代价模型的合理与否都会影响CBO选择最优计划。
从上述描述可知，CBO是优于RBO的，原因是RBO是一种只认规则，对数据不敏感的呆板的优化器，而在实际过程中，数据往往是有变化的，通过RBO生成的执行计划很有可能不是最优的。