01、为什么选择 CBO？
随着数据量和业务场景的持续激增， 经过 RBO 优化器处理得到的计划，其执行速度可能会较为缓慢。如果单靠 DBA 人为的进行优化，那么工作量又将非常的巨大。
面对这种现实情况，亟需一个能根据当前数据量和数据特征自动进行优化的优化器来解决此问题，CBO 优化器也由此应运而生。CBO 优化器通过收集数据库内部相关信息进行计算，从而实现动态调整执行计划。
02、整体思路
数据库 CBO 优化思路主要是通过 SQL 生成抽象的语法树探索出所有可能的查询路径，然后选出一条代价最小的路径。
此代价可以简单的理解为执行所用的消耗，SQL 下发给执行器去执行，期间会使用到 CPU 资源，IO 资源，网络传输资源等，这些资源总和就是执行一条路径的代价。
03、如何产生所有的查询路径？
查询计划分为逻辑计划和物理计划，逻辑计划是我们看到的 SQL 执行的计划步骤，例如：select * from t1 join t2 where t1.a=t2.a;
**1、逻辑计划：**逻辑上执行需要的相关操作的计划
对于逻辑计划的探索：
1、对于 Inner join 可以直接交换左右两表的顺序。此外，在进行 hash join 时，数据量小的表前置会优于数据量大的表前置。
2、对于 left join 或 right join 可以交换顺序并修改连接类型
3、可以通过交换和结合产生新的 join 顺序，例如 t1 join t2 join t3 通过交换和结合后会产生以下 6 中 join 顺序的路径
目前 join 顺序有两种主要的探索算法：
1）动态规划算法
2）贪心算法。由于动态规划算法会遍历所有路径
随着 join 层级的增加探索路径呈指数级增长，因此要限制探索的层级，不然会在探索时耗费太多时长导致得不偿失。
**2、物理计划：**实际执行时确定的相关算子计划
对于物理计划的探索：
对于分布式的存储引擎还需要考虑表的分布方式，例如：t1 hash join t2 on t1.a=t2.a
在各个节点单独做 join 可以充分利用分布式各个节点的计算资源。重分布会增加额外的 CPU 计算、网络传输和磁盘 IO 的代价，广播会使数据量按节点数倍数增加，因此数据量大的情况下广播的代价非常高。
04、如何进行评估？
在进行评估之前需要提前收集好所涉及到的表的统计信息，一般统计信息会包含表中的数据总量、null 值数量、distinct 值数量、直方图或出现频率高的值。
目前收集方式分为手动收集（输入 SQL 针对表或表中某列进行分析）、自动收集（定时对某些表进行信息分析、当表的数量变化超过设定值后收集等）。
手动收集 SQL：create statistics myname from t1；收集的统计信息存储在 system 库中的 system.table_statistics 表中。
根据采集到的统计信息我们会进行数据估算，例如 where 条件的过滤，经过过滤后剩余条数可以根据 distinct 值进行估算。
比如 t1.a 的不同值中有 10 个，分别为 1~10 ，那么 t1.a=10 的概率就是 10%。原表中如果有 100 行数据，那么估算经过 t1.a=10 过滤后 t1 表中剩余 10 条。另外估算还可以依据两表 join 的选择率、union 的选择率、group by 的选择率等。
计划的评估是从底向上进行，例如：t1 随机分布，t2 随机分布，t1 hash join t2 on t1.a=t2.a where t1.b<10 and t2.c > 10 评估 t1 重分布和 t2 重分布情况的代价为：
1、 根据 t1 的单表条件和 t1 的 a 列中的统计信息估算出 t1 过滤完后剩余的条数 M
2、 根据 t2 的单表条件和 t2 的 a 列中的统计信息估算出 t2 过滤完后剩余的条数 N
3、 按照规则计算 t1 重分布的代价和 t2 重分布的代价（ M*（单条 CPU 计算 hash 的代价 + 单条网络传输代价））
4、 计算一个节点 hash join 的代价（准备 hash 表的代价+匹配 hash表的代价+根据是否需要落盘的 IO 代价）
5、在每层会计算出当前层所有路径代价最小的一条路径向上传递。
