通过分析SQL语句的执行计划优化SQL(三)

核心提示： 对于需要访问跨节点(即通常说的服务器)数据库上数据的查询来说，存在network代价，通过分析SQL语句的执行计划优化SQL(三)(5)，用来量化传输操作耗费的资源，查询远程表的查询或执行分布式连接的查询会在network代价方面花费比较大，这句话并不是指在ORACLE 10G中不能使用R

对于需要访问跨节点(即通常说的服务器)数据库上数据的查询来说，存在network代价，用来量化传输操作耗费的资源。查询远程表的查询或执行分布式连接的查询会在network代价方面花费比较大。

在使用CBO时，需要有表和索引的统计数据(分析数据)作为基础数据，有了这些数据，CBO才能为各个执行计划计算出相对准确的代价，从而使CBO选择最佳的执行计划。所以定期的对表、索引进行分析是绝对必要的，这样才能使统计数据反映数据库中的真实情况。否则就会使CBO选择较差的执行计划，影响数据库的性能。分析操作不必做的太频繁，一般来说，每星期一次就足够了。切记如果想使用CBO，则必须定期对表和索引进行分析。

对于分析用的命令，随着数据库版本的升级，用的命令也发生了变换，在oracle 8i以前，主要是用ANALYZE命令。在ORACLE 8I以后，又引入了DBMS_STATS存储包来进行分析。幸运的是从ORACLE 10G以后，分析工作变成自动的了，这减轻的DBA的负担，不过在一些特殊情况下，还需要一些手工分析。

如果采用了CBO优化器，而没有对表和索引进行分析，没有统计数据，则ORACLE使用缺省的统计数据(至少在ORACLE 9I中是这样)，这可以从oracle的文档上找到。使用的缺省值肯定与系统的实际统计值不一致，这可能会导致优化器选择错误的执行计划，影响数据库的性能。

要注意的是：虽然CBO的功能随着ORACLE新版本的推出，功能越来越强，但它不是能包治百病的神药，否则就不再需要DBA了，那我就惨了！！！实际上任何一个语句，随着硬件环境与应用数据的不同，该语句的执行计划可能需要随之发生变化，这样才能取得最好的性能。所以有时候不在具体的环境下而进行SQL性能调整是徒劳的。

在ORACLE8I推出的时候，ORACLE极力建议大家使用CBO，说CBO有种种好处，但是在那是ORACLE开发的应用系统还是使用基于规则的优化器，从这件事上我们可以得出这样的结论：1) 如果团队的数据库水平很高而且都熟悉应用数据的特点，RBO也可以取得很好的性能。2）CBO不是很稳定，但是一个比较有前途的优化器，Oracle极力建议大家用是为了让大家尽快发现它的BUG，以便进一步改善，但是ORACLE为了对自己开发的应用系统负责，他们还是使用了比较熟悉而且成熟的RBO。从这个事情上给我们的启发就是：我们在以后的开发中，应该尽量采用我们熟悉并且成熟的技术，而不要一味的采用新技术，一味采用新技术并不一定能开发出好的产品。幸运的是从ORACLE 10G后，CBO已经足够的强大与智能，大家可以放心的使用该技术，因为ORACLE 10G后，Oracle自己开发的应用系统也使用CBO优化器了。而且ORACLE规定，从ORACLE 10G开始，开始废弃RBO优化器。这句话并不是指在ORACLE 10G中不能使用RBO，而是从ORACLE 10G开始开始，不再为RBO的BUG提供修补服务。