0

这是一个关于 Oracle (~11g) 查询优化的非紧急问题。这并不紧急，因为查询目前在要求范围内表现良好，但我想知道是否建议优化我的查询。

该查询通过外键将最多几千条记录的表连接到其他 4 条记录，因此其他表中只有一个匹配行，大约有 30 到 300 条记录。它选择主表的几乎所有 (c. 40) 列和其他表中的 3 列。使用嵌入式 SQL 访问数据库，该源文件经过预处理以sed使其适应以下两种平台之一：（正常）AIX 上的 Oracle 或 VMS 上的 Oracle Rdb。在这两种情况下，查询都在与 DB 相同的机器上运行，Rdb 的性能往往稍好一些。

我有疑问的一点是，为了实现可选的选择标准，我有一个条件:pid = 0 OR t.pid = :pid和两个 like t.name like :name，其中:pid和:name是主机变量，并且:name设置"%"为何时不需要此标准，否则为实际名称。

我这样写是为了保持代码简单，即避免动态 SQL 的复杂性和编写（文本上）相当大的查询的几个变体的冗余——这些选项中的任何一个都可能会增加维护成本。由于数据库并不大（并且预计将保持大致相同的大小）并且性能在范围内，我目前认为是合理的。

这种方法是鲁莽的、明智的务实还是介于两者之间？

4

1 回答 1

1

我认为在不知道查询优化器在可能引起关注的情况下正在做什么的情况下很难回答。

您可能想看看在 :pid 等于 0 和不等于 0 时如何优化 ":pid = 0 OR t.pid = :pid"，对于 "t.name like '%'" 也是如此。

如果 :pid 真的是一个绑定变量，那么它可能无关紧要，但我关心的是执行计划在 99% 的情况下通过使用 :pid 的值与“不同的值”进行优化的查询来定义0”，并且 1% 的时间 :pid 具有其他值。两者中的一个表现良好，而另一个表现糟糕，这绝不是闻所未闻的。

当您执行“t.name like 'abc'”时，我肯定会非常关心检查优化器的作用，因为 LIKE 往往不使用索引。可能查询优化器将其转换为“t.name = 'abc'”，也可能不是。

如果你有时间的话，这听起来像是一个不错的低优先级调查。

于 2015-05-06T19:44:28.353 回答