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。
————————————————
