以一个比较两本字典来做例子:
一本字典有索引目录(dict a), 一本没有(dict b) 现在要找出所有a开头的单词的异同 那么比较的时候,你会怎么比较? 合理的做法应该是以没有索引的字典dict b开始, 找到a开头的那一页, 然后对于每个单词, 通过使用索引在dict a中找到相应的条目 如果反过来, 效率会相同吗? 驱动表，通俗的讲就是先从哪个表开始检索,良好的驱动表是成功优化的一半 例如： select * from a,b where a.id = b.id and a.姓名 = '美格瑞恩' and b.性别 = '女'; 在a,b表同等数量级的情况下，显然用a表做为驱动表比较好 因为姓名相对于性别来说可以过滤掉更多的数据 所以想办法使你的执行计划先扫描a表再通过nest loop与b表关连比较理想一般而言，2个表的时候，选择小表；3个或者以上的时候，选择关联比较多的表作为驱动表
不过，事无绝对，看个案例先： 有两个表T1和T2，可以假设T1存放姓名、ID这些基本信息，每行较短 而T2也有ID列和一些说明、备注类信息，每行长的可能有一两千个字节 对于这两个表，使用嵌套循环连接，T1表占的块数比较少，是小表 而T2表占的块数几倍于T1，是大表。那么，应该T1做驱动表更好一些，但实际却是T2大表做驱动表更好 一个不知道DBA还是开发，不知道这一点，为了强制小表T1做驱动表，写了类如下语句： select /*+ ordered use_nl(t1,t2) */ from t2,t1 where t1.id=t2.id; 后来这个语句造成了一些性能问题。通过了解嵌套循环的工作方式，发现这里的确是大表做驱动表好一些 这里就说明了一个问题，都说嵌套循环要小表做驱动表，如果不知道这是为什么，这很容易造成人云亦云 这样只知其表，而不知其里，很容易影响以后在某些问题上做出的判断驱动表(driving table/outer table)又称为外层表，驱动表仅仅用于nested_loop join 和 hash join
驱动表是用来驱动查询的 在CBO中，优化器会根据cost自动选择驱动表，与表的顺序无关 通常情况下，驱动表的选择性较高(该列唯一键与列的比值较高)，where中的限制条件较多，返回的行数较少的表适合做驱动表 事实上，大表有时候也会做驱动表，只要在大表上面限制条件较多，从大表上面返回的行数较少的话，大表也适合做驱动表 始终要记住的就是返回的结果集(某个表被过滤后的数据，或者某些表join 产生的数据)较小的表适合做驱动表 也就是说，哪个返回数据少 ，哪个就做驱动表，即连接操作应从返回较少行上驱动 我们在看执行计划的时候，离nested loops，hash join 近的表就是驱动表，也就是说执行计划中靠上的表是驱动表 以下是几个快速判断驱动表的经验，可能有错哦： (1)用于连接的子句的列应被索引、在Where子句中应尽量利用索引，而不是避开索引 (2)连接操作应从返回较少行上驱动 (3)如果所连接的表A和B，A表长度远远大于B表，建议从较大的A表上驱动 (4)如果Where子句中含有选择性条件,Where No=20，将最具有选择性部分放在表达式最后 (5)如果只有一个表有索引，另一表无索引，无索引的表通常作为驱动表。如A表的No列以被索引 而B表的No列没被索引，则应当B表作为驱动表，A表作为被驱动表 RULE 下所谓驱动表 我们以 nested loop 为例： 如果两个表连接字段都没有索引（通常这个时候是 sort merge / hash join），则驱动表会选择后者 若两个表其中有一个有索引而另外一个没有索引，则驱动表是没有索引那一个，跟顺序无关 若两个表都有索引，则驱动表为 后面 那一个表 所以事实上，RULE下，只有在两个表都存在连接字段的索引的情况下才需要考虑顺序问题 也就是小表放在后面大表放在前面(当然到底哪个好这实际上还跟符合条件的记录数、数据分布等因素相关！，所以应该以实际测试为准) 而如果是 CBO 下，则跟顺序无关