您可能对为以上查询生成的执行计划并不满意。尤其是,所处理的行数可能非常大。由于 SQL 调整的主要目标是避免访问对结果没有任何影响的行,因此可能要继续调整查询以优化性能。对查询中包含的 XPath 表达式进行重新建模后,可以再次重试它,如下所示:
SELECT count(*) FROM oe.purchaseorder, XMLTable( 'for $i in /PurchaseOrder where $i/User = "CJOHNSON" return $i/User' PASSING OBJECT_VALUE) ptab; 这次,输出应如下所示: COUNT(*) ---------- 9 Execution Plan --------------------------------------------------- Plan hash value: 3411896580
---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 29 | 7 (0) | 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 29 | | | | 2 | NESTED LOOPS | | 1 | 29 | 7 (0) | 00:00:01 | | 3 | FAST DUAL | | 1 | | 2 (0) | 00:00:01 | |* 4 | TABLE ACCESS FULL | PURCHASEORDER | 1 | 29 | 5 (0) | 00:00:01 | Predicate Information (identified by operation id): ---------------------------------------------------
4 - filter("PURCHASEORDER"."SYS_NC00022$"='CJOHNSON' AND SYS_CHECKACL("ACLOID","OWNERID",xmltype('... |
您可以看到,以上显示的查询生成相同的最终结果,但它们的执行计划并不相同。查看最后一个示例中的 XQuery 表达式,您可能会注意到它迭代顶层 PurchaseOrder 元素,其中的每个 PurchaseOrder 元素都表示基于 PurchaseOrder XMLType 模式的表中的一行。这意味着实际上重写 XQuery 表达式,以迭带基础对象表(用于存储分解的 PurchaseOrder 文档)中的行。与查询要迭代不表示基础表中的单个行的 XML 元素相比,该方法的性能更好一些。
但在某些情况下,很难发现 XQuery 表达式的哪个构造将使某些查询的性能更好。这就是为什么最好在开发阶段使用调整工具的原因。
将动态变量绑定到 XQuery 表达式
如果您对本文有任何疑问或者建议,请到讨论区发表您的意见:
>>
论坛入口 <<
上一篇:
Oracle数据库的备份及恢复策略研究 下一篇:
Oracle OCCI的一个简单的包装类的实现
【文章评论】
【收藏本文】
【推荐好友】
【打印本文】
【我要投稿】 【论坛讨论】