|
| |
 精品推荐 |
 |
|
| |
|
|
|
|
通过分析SQL语句的执行计划优化SQL(四)
|
日期：2008年5月19日 作者： 查看:[大字体
中字体 小字体]
|
2 sorts (memory)
0 sorts (disk)
1 rows processed
总结：
因为上两个查询都是采用nested loop循环，这时采用哪个表作为driving table就很重要。在第一个sql中，小表(SUPER_USER)作为driving table，符合oracle优化的建议，但是由于SWD_BILLDETAIL表中cn列的值有很多重复的，这样对于SUPER_USER中的每一行，都会在SWD_BILLDETAIL中有很多行，利用索引查询出这些行的rowid很快，但是再利用这些rowid去查询SWD_BILLDETAIL表中的user_class列的值，就比较慢了。原因是这些rowid是随机的，而且该表比较大，不可能缓存到内存，所以几乎每次按照rowid查询都需要读物理磁盘，这就是该执行计划比较慢的真正原因。从结果可以得到验证：查询出1186387行，需要利用rowid从SWD_BILLDETAIL表中读取1186387次，而且大部分为从硬盘上读取。
反其道而行之，利用大表(SWD_BILLDETAIL)作为driving表，这样大表只需要做一次全表扫描(而且会使用多块读功能，每次物理I/O都会读取几个oracle数据块，从而一次读取很多行，加快了执行效率)，对于读出的每一行，都与SUPER_USER中的行进行匹配，因为SUPER_USER表很小，所以可以全部放到内存中，这样匹配操作就极快，所以该sql执行的时间与SWD_BILLDETAIL表全表扫描的时间差不多(SWD_BILLDETAIL全表用11分钟，而此查询用20分钟)。
另外：如果SWD_BILLDETAIL表中cn列的值唯一，则第一个sql执行计划执行的结果或许也会不错。如果SUPER_USER表也很大，如500万行，则第2个sql执行计划执行的结果反而又可能会差。其实，如果SUPER_USER表很小，则第2个sql语句的执行计划如果不利用SUPER_USER表的索引，查询或许会更快一些，我没有对此进行测试。
所以在进行性能调整时，具体问题要具体分析，没有一个统一的标准。
（出处：清风网络学院）
上一篇:通过分析SQL语句的执行计划优化SQL(三)
下一篇:数据库Oracle9i的企业管理器介绍
|
| 相关文章： |
|
|
|
| 相关软件： |
|
|
|
|
