还是有区别的：应该用大表作为驱动表3.1 SQL语句的优化
SQL语句的执行速度，可以受很多因素的影响而变化。但主要的影响因素是：驱动表、执行操作的先后顺序和索引的运用。可以由很多不同的方法间接地改变这些因素，以达到最优的执行速度。这里主要探讨当对多个表进行连接查询时应遵循的优化原则：
(1) 用于连接的子句的列应被索引、在Where子句中应尽量利用索引，而不是避开索引。
(2) 连接操作应从返回较少行上驱动。
(3) 如果所连接的表A和B，A表长度远远大于B表，建议从较大的A表上驱动。
(4) 如果Where子句中含有选择性条件,Where No=20，将最具有选择性部分放在表达式最后。
(5) 如果只有一个表有索引，另一表无索引，无索引的表通常作为驱动表。如A表的No列以被索引，而B表的No 列没被索引，则应当B表作为驱动表，A表作为被驱动表。
(6) 若用于连接的列和Where子句中其他选择条件列均有索引，则按各个索引对查询的有效性和选择性分别定出级别，结合表中具体数据构成情况，从中选出优化路径，一般需要考虑：子句中哪些列可以使用索引、哪些索引具有唯一性及被查询表行数目等。
问题：1、何谓驱动表？（怎么判断哪个表当驱动表）
2、如果所连接的表A和B，A表长度远远大于B表，建议从较大的A表上驱动
这句话怎么理解呀？
3、连接操作应从返回较少行上驱动
这句话该怎么理解呀？能举个例子么？
---------------------------------------------------------------
以下是三千兄的解释：
驱动表是sql执行路径中用来最先查询的表，比如本例中第一句sql用explain plan来看
执行路径的化，应该是先搜索D表，然后根据D表中记录和WHERE条件去搜索别的表，
那样就需要搜索30万次（如果WHERE条件中没有对D的确定值限制）。而第二句SQL就会以
A表作为驱动，那样搜索的次数就大大减小了。但是这种情况只有在采用的RULE-BASED
优化器或者采用了COST-BASED优化器而相关表没有STATISTICS的时候才会出现的。
如果采用了COST-BASED优化器而且对所有的表都进行了分析的话，ORACLE就能自动根据COST
值来确定优化路径，那样表的顺序就不是很有关了。所以定期地对大的、更新频繁的表作分
析是非常重要的。
---------------------------------------------------------------
rule 模式下的规则：
有两个索引存在的情况下，from后面大表在前
有一个索引，则顺序无关
都没有索引，则大表应该在后（这个效率我几次测试相差有60%）
---------------------------------------------------------------
biti_rainy(biti_rainy)：
现在恐怕没多少系统是用rule-based作为默认优化器的，但是实际中用户不注意对表的分析，系统被迫采用rule-based的例子倒是非常常见。
老兄在哪里高就？我最近一个项目很大，所以很忙，有空多交流。
SQL语句的执行速度，可以受很多因素的影响而变化。但主要的影响因素是：驱动表、执行操作的先后顺序和索引的运用。可以由很多不同的方法间接地改变这些因素，以达到最优的执行速度。这里主要探讨当对多个表进行连接查询时应遵循的优化原则：
(1) 用于连接的子句的列应被索引、在Where子句中应尽量利用索引，而不是避开索引。
(2) 连接操作应从返回较少行上驱动。
(3) 如果所连接的表A和B，A表长度远远大于B表，建议从较大的A表上驱动。
(4) 如果Where子句中含有选择性条件,Where No=20，将最具有选择性部分放在表达式最后。
(5) 如果只有一个表有索引，另一表无索引，无索引的表通常作为驱动表。如A表的No列以被索引，而B表的No 列没被索引，则应当B表作为驱动表，A表作为被驱动表。
(6) 若用于连接的列和Where子句中其他选择条件列均有索引，则按各个索引对查询的有效性和选择性分别定出级别，结合表中具体数据构成情况，从中选出优化路径，一般需要考虑：子句中哪些列可以使用索引、哪些索引具有唯一性及被查询表行数目等。
问题：1、何谓驱动表？（怎么判断哪个表当驱动表）
2、如果所连接的表A和B，A表长度远远大于B表，建议从较大的A表上驱动
这句话怎么理解呀？
3、连接操作应从返回较少行上驱动
这句话该怎么理解呀？能举个例子么？
---------------------------------------------------------------
以下是三千兄的解释：
驱动表是sql执行路径中用来最先查询的表，比如本例中第一句sql用explain plan来看
执行路径的化，应该是先搜索D表，然后根据D表中记录和WHERE条件去搜索别的表，
那样就需要搜索30万次（如果WHERE条件中没有对D的确定值限制）。而第二句SQL就会以
A表作为驱动，那样搜索的次数就大大减小了。但是这种情况只有在采用的RULE-BASED
优化器或者采用了COST-BASED优化器而相关表没有STATISTICS的时候才会出现的。
如果采用了COST-BASED优化器而且对所有的表都进行了分析的话，ORACLE就能自动根据COST
值来确定优化路径，那样表的顺序就不是很有关了。所以定期地对大的、更新频繁的表作分
析是非常重要的。
---------------------------------------------------------------
rule 模式下的规则：
有两个索引存在的情况下，from后面大表在前
有一个索引，则顺序无关
都没有索引，则大表应该在后（这个效率我几次测试相差有60%）
---------------------------------------------------------------
biti_rainy(biti_rainy)：
现在恐怕没多少系统是用rule-based作为默认优化器的，但是实际中用户不注意对表的分析，系统被迫采用rule-based的例子倒是非常常见。
老兄在哪里高就？我最近一个项目很大，所以很忙，有空多交流。
根据Oracle优化路径
rule 模式下的规则：1、有两个索引存在的情况下，from后面大表在前。小表（返回记录少的表，不是记录少的表）在最后，作为驱动表，Oracle处理SQL语句是从左到右2、有一个索引，则顺序无关3、都没有索引，则大表应该在后
不过这样差别就大了：select usr.* from GL_JE_LINES a,fnd_user usr where usr.user_id=a.created_byselect usr.* from fnd_user usr,GL_JE_LINES a where usr.user_id=a.created_by
你是这边的高手哦！！的你的一本手册，至今尤记在心！！谢谢！
大家好好想想。
[email protected]
请发到[email protected]