Question

我的查询看起来像这样：

select xmlelement("rootNode",
    (case
       when XH.ID is not null then
     xmlelement("xhID", XH.ID)
       else
     xmlelement("xhID", xmlattributes('true' AS "xsi:nil"), XH.ID)
    end),
    (case
       when XH.SER_NUM is not null then
     xmlelement("serialNumber", XH.SER_NUM)
       else
     xmlelement("serialNumber", xmlattributes('true' AS "xsi:nil"), XH.SER_NUM)
    end),
/*repeat this pattern for many more columns from the same table...*/
FROM XH
WHERE XH.ID = 'SOMETHINGOROTHER'

它很丑陋而且我不喜欢它，它也是执行速度最慢的查询（还有其他类似的形式，但更小，并且它们没有造成任何重大问题 - 但）。维护相对容易，因为这主要是生成的查询，但我现在关心的是性能。我想知道所有这些案例表达式有多少开销。

为了查看是否存在任何差异，我将此查询的另一个版本写为：

select xmlelement("rootNode",
                   xmlforest(XH.ID, XH.SER_NUM,...

（我知道这个查询不会产生完全相同的东西，我的计划是将处理重命名和xsi：nil属性的逻辑移到XSL或者PL / SQL上）

我试图获得两个版本的执行计划，但它们是相同的。我猜测逻辑没有被纳入执行计划。我的直觉告诉我第二个版本应该执行得更快，但是我想要一些方法来证明（除了在查询之前和之后编写带有时序语句的PL / SQL测试函数并一遍又一遍地运行该代码以获得测试样本）。

是否可以了解案件的费用是多少？

另外，我可以在使用解码函数时编写案例。这会表现得更好（比案例陈述）吗？

Answer 1

SELECT列表中的任何内容，除非是用户定义的函数，它读取表或视图，或嵌套的子选择，通常可以忽略，以便分析查询的性能。

打开连接属性并设置值SET STATISTICS IO on。查看发生了多少次读取。查看查询计划。您的索引是否正确使用？你知道如何分析计划吗？

Answer 2

出于性能调优的目的，您正在处理此声明：

SELECT *
FROM XH
WHERE XH.ID = 'SOMETHINGOROTHER'

该查询如何执行？如果它的返回时间明显少于XML版本，那么你需要考虑函数的性能，但是如果是这样的话我会很惊讶（哦，好吧！）。

这会返回一行还是几行？如果是一行，那么你只有两件事可以使用：

是索引的XH.ID，如果是，是否正在使用索引？
“同一个表中的更多列”是否表示chained rows？

如果查询返回多行，那么......实际上，你有两件事要处理。这只是关于索引的重点不同。如果索引的聚类因子非常差，那么避免使用索引支持全表扫描可能会更快。

除此之外，您还需要查看物理问题 - I / O瓶颈，不良互连，狡猾的磁盘。调整查询的范围如此受限制的原因是 - 如所示 - 它是单个表，单列读取。大多数调整都是关于有效加入。现在，如果XH发生了对复杂查询的看法，那么这是另一回事。

Answer 3

您可以使用旧的tkprof来分析统计信息。打开统计数据的多种形式的ALTER SESSION之一。如果光标位于PL / SQL代码块中，DBMS_PROFILER包还会收集统计信息。

查询中的逻辑成本

3 个答案: