SQL优化与CBO

SQL优化与CBO
SQL从诞生到现在已经有几十年的时间了，尽管前几年nosql一度自我感觉良好号称要去掉sql，却也被现实教做人不得不改口，说是自己其实是not only sql，从这点可以看出sql语言的强大和通用。

说回sql，sql是一种声明式语言，所谓声明式，就是用户只需要告诉机器我要什么样的结果，机器会自己摸索并帮助用户找到结果返回。与之相比的是命令式语言，需要详细告诉机器如何执行，比如常见的编程语言。

那么作为声明式语言，如何帮助用户高效准确地获取到结果，这就是机器的责任。在这其中，SQL优化是许多研究者一直在探索的一个领域。

SQL优化的发展，则可以分为两个阶段，即RBO（Rule Base Optimization），和CBO（Cost Base Optimization）。

先简单说下RBO，RBO主要是开发人员在使用SQL的过程中，有些发现有些通用的规则，可以显著提高SQL执行的效率，比如最经典的filter下推：

图片的意思很明显，我们都知道join是非常耗时的一个操作，且性能与join双方数据量大小呈线性关系（通常情况下）。那么很自然的一个优化，就是尽可能减少join左右双方的数据量，于是就想到了先filter再join这样一个rule。而非常多个类似的rule，就构成了RBO。

但后面开发者发现，RBO确实能够对通用情况下对SQL进行优化，但在有些需要本地状态才能优化的场景却无能为力。比如某个计算引擎，在数据量小于XXX的时候，可以做一些特殊的优化操作，这种场景下RBO无能为力。

而这就是CBO出现的背景了，CBO全称Cost Base Optimization，基于Cost的优化，其中Cost指的是执行SQL所需要的资源，通常是行数rowcount，CPU，内存，IO等等。基于Cost意思就是根据需要的资源，做更加智能的优化。

最典型的例子，就是Spark的join的选择。在Spark中，join会触发Shuffle操作，这种操作类型是非常消耗资源的。而Spark有三种类型的join，分别是broadcase join，将小的表广播到所有节点，在内存中hash碰撞进行join，这种join避免节点间shuffle操作，性能最好，但条件也苛刻。第二种是hash join，就是普通的shuffle join。第三种是sort merge join，先排序然后join，类似归并的思想，排序后能减少一些hash碰撞后的数据扫描，在join双方都是大表的情况下性能较好。

选择哪种类型的join，就要根据数据类型来选择，如果一方是小表，就用broadcase join，如果双方都是大表，就用sort merge join，否则就是 hash join。而这就需要用到Cost的信息了。

小结一下，RBO和CBO的区别大概在于，RBO只会无脑得应用提供的rule，而CBO会根据给出的Cost信息，智能应用rule，求出一个Cost最低的执行计划。需要纠正很多人误区的一点是，CBO其实也是基于rule的，接触到RBO和CBO这两个概念的时候，很容易将他们对立起来。但实际上CBO，可以理解为就是加上Cost的RBO。
————————————————
版权声明：本文为CSDN博主「zzzzMing」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/jiangzhali1623/article/details/108628277

1、优化器的优化方式

Oracle的优化器共有两种的优化方式,即基于规则的优化方式(Rule-Based Optimization,简称为RBO)和基于代价的优化方式(Cost-Based Optimization,简称为CBO)。

A、RBO方式：优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则。比如我们常见的,当一个where子句中的一列有索引时去走索引。

B、CBO方式：依词义可知,它是看语句的代价(Cost)了,这里的代价主要指 Cpu和内存。优化器在判断是否用这种方式时,主要参照的是表及索引的统计信息。统计信息给出表的大小 、有少行、每行的长度等信息。这些统计信息起初在库内是没有的,是你在做analyze后才出现的,很多的时侯过期统计信息会令优化器做出一个错误的执行 计划,因些我们应及时更新这些信息。在Oracle8及以后的版本,Oracle列推荐用CBO的方式。

我们要明了,不一定走索引就是优的 ,比如一个表只有两行数据,一次IO就可以完成全表的检索,而此时走索引时则需要两次IO,这时对这个表做全表扫描(full table scan)是最好的。

https://blog.csdn.net/zhifeiyu2008/article/details/8374089