为何小表驱动大表？
数据库最伤神的是数据库连接。
1.建立2次连接，每次进行上百万的数据集的查询
2.上百万次的连接，每次进行2个数据集的查询
left join 的时间开销类似于笛卡尔积，相当费时，如果关联字段是索引字段，可以减少时间复杂度，但是还是非常费时。
left 的优化：首先，mysql都是使用（Nested Loop ）循环套嵌的方式实现join，这里包括两个部分：驱动表结果集作为条件连接被驱动表X，被驱动表根据驱动表结果查询数据集Y。时间复杂度（X*Y），这里的第二部分是数据库内部的操作，涉及io，cpu等的操作很少，而且可以使用索引优化。第一部分是表的连接，这里是需要时间的，时间复杂度，CPU，io操作等都耗费比内部操作更多的时间。所以，以少的实际结果集（where筛选后）驱动大的结果集，大的结果集使用索引，这种方式能够最大层度的减少时间复杂度。也就是永远使用小的结果集驱动大的结果集。
这里规定join连接单次总用时为m1，被驱动表一次查询使用时间为m2;则总的查询时间为：
X*m1+Y*m2;这里的m1大于m2则 X相对于Y越小，结果越小;
B平衡树的索引结构，三种索引的速度以及覆盖范围排序: 1覆盖索引>= 2聚集索引>3非聚集索引。 1和2中大于的部分不是速度，而是适用范围，1覆盖索引能够根据业务自定义，而2基本都是主键，适用性不强，但是覆盖索引占用内存比较大，这个是一个限制条件。
索引总共分为三种，聚集索引，非聚集索引，覆盖索引
非聚集索引会先找到聚集索引的唯一主键，然后根据聚集索引查找值，例外的是覆盖索引（多列索引）：查询列在索引列中，不需要再到聚集索引中查找一遍。
没有主键（聚集索引）的表加数据堆，数据堆是通过使用索引分配图（IAM）页来维护的。当在数据堆上创建了非聚簇索引时，叶级中包含了指向数据页的行标识符。行标识符指定记录行的逻辑顺序，由文件ID、页号和行ID组成
nested join
嵌套循环连接将驱动表(外表)和被驱动表(内表)进行join，读取外表的每一行，和内表进行比较操作，数据库一般将建有索引的表作为内表。
通过伪代码可以看到，执行主要分三步：
选定驱动表
选定另一张表为内表
将驱动表中每一行和内表中的记录逐一进行匹配
hive
hive存储基于hdfs，计算主要是基于mapreduce框架。
连接类型
map side join
如果join中有一张表较小，这种情况下，可以使用map join，不需要进行reduce操作。
select /*+ mapjoin(b) */
a.key
, a.value
from a
join b
on a.key = b.key
如果join的表在join列上进行了分桶，一张表的桶数是其它表的倍数，这种情况下，相关桶之间在map端进行join操作，称为bucketized map-side join,通过如下参数开启
-- 方法一
set hive.optimize.bucketmapjoin = true;
map join执行步骤：
本地工作：在本地机器读入数据，在内存中建立hash表，然后写入本地磁盘并上传至hdfs。最后将hash表写入分布式缓存中
map任务:将数据从分布式缓存中读入内存，将表中数据逐一和hash表匹配。将匹配到数据进行合并并写入hdfs中
无reduce任务
common join(reduce side join)
若两种表都较大在map端无法缓存进内存，此时只能在reduce端进行join
如果多张表中用同一列进行join操作，那么hive会将其转成一个map/redcuce job
谓词下推(Predicate Pushdown)
原理
对于left join，先给出如下定义:
保留行表:outer join中返回所有行的表，如left outer join中的左表，right outer join中的右表
空供应表：如果和主表没有匹配上返回空值的表，如left outer join中的左表，right outer join中左表
join过程中谓词：写在join过程中的过滤条件
join后谓词：写在where条件中的过滤条件
存在如下反向规则:
Join过程中谓词不能推移到保留行表
join后谓词不能推移到空供应表
正向解释下：join过程中的过滤条件可以推移到空供应表上，where 过程中的条件可以推移到保留行表。
=